You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gillespie <ep...@pretzelnet.org> on 2002/05/01 21:40:16 UTC
svn modules (was Re: Features and release dates)
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Actually, modules just got a whole lot closer. See recent changes to
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=517
>
> Anyone feel like taking it on?
A co-worker and i have been kicking around the idea of writing code
for symlinks in the repository for internal use (we're anxious to
dump CVS :). We would of course contribute the patch, but i figured
you wouldn't take it until after 1.0. Since it sounds like you
might, let me describe the approach we were planning and see what
you think.
I don't like the text-file based modules. CVS does that and it
drives me nuts. Subversion doesn't really need to duplicate this
feature. All that is necessary is a kind of symlink in the repo.
Clients don't even know that something is a link; they see only a
file or directory (whatever the link points to). We'll probably
want some way for the client to discover if a node is a link or
not (the user might want to know for example), but under normal
operation the client neither knows nor cares.
Let's look at how this would work:
svn co http://foo/repo/trunk/foo/
cd foo
svn ln http://foo/repo/trunk/doctools/ .
svn ci
svn up # at this point the doctools directory becomes populated
# How many copies of the GPL do you have in your CVS repo? :)
svn ln http://foo/repo/trunk/licenses/BSD COPYING
When committing to a link, the client behaves as it always has.
But the ra layer knows this is a link and performs the action on
the link target.
This is more general-purpose and much more flexible than modules.
What does everyone think?
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 01 May 2002 14:40, Eric Gillespie wrote:
> svn ln http://foo/repo/trunk/doctools/ .
Another comment from the lowly user: I like this a lot. The one thing I liked
about Visual Source Safe is that it let us link directories into other parts
of the tree, and changes would appear in both places. Copying is totally
great (something that VSS didn't do directly), but linking is useful too.
Even if a text-based modules file is still supported, links should be too.
Or is this handled by symlinks? What happens to symlinks in Windows with the
current version, or do they work at all? Is it possible to create symlinks
with svn from a client running Windows? If not, then 'svn link' should
supplement that.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE80GUJNSZCJx7tYycRAvu3AKC4HcABJ759OIckIyehU2nV3PQxtwCfYsBu
ZdH3CsYXIoF2JY5xQlKUaFg=
=3dTU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Ronald V. Simmons" <Va...@thesimmonses.net> writes:
> directory structure in a globally efficient manner... But the problem
> remains that anyone who can commit in one directory can commit in all
> and I have yet to find a combination of LOCATION tags which will let me
> limit write access to subdirectories in the repository.
CVS uses a hack for ACLs. Why can't you use the same hack with
svn? That is, check the username and directory in the pre-commit
hook and bomb if the user isn't allowed to commit in that directory.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by "Ronald V. Simmons" <Va...@thesimmonses.net>.
Ok time to quit being a lurker..
> Unfortunately, symlinks in the repo aren't enough. I believe that Subversion
> will be more multiple-repository-prone than CVS. As an example:
>
> The ASF has one CVS repository, which contains modules for each project:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
> we're have a separate SVN repository for each project. I think the projects
> will want their own directory organization (trunk, branches, tags, whatever)
> and their own (partitioned) set of log messages / revision changes.
>
> As a result, cross-repository "modules" are quite important for SVN. It also
> means that when the ASF switches over to SVN, we can set up a "module" for
> Subversion that references the ASF SVN repositories.
This actually raises a question I've been trying to figure out the answer to for a while now:
I need to control access to the repository at a finer grain than the documentation would indicate is possible. In the example gstein mentions, it's as if I need one set of committers for for httpd-2.0 and another for apr and another for apr-util, with all the sets disjoint. Since SVN is currently lacking the module linking capabilities outlined above, I've placed all my modules in one repository and arranged my directory structure in a globally efficient manner... But the problem remains that anyone who can commit in one directory can commit in all and I have yet to find a combination of LOCATION tags which will let me limit write access to subdirectories in the repository.
(I'm authenticating against OpenLDAP if that matters).
any ideas greatly appreciated.
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
>
> As for the SQL backend, it would be good if the same instance of the DB could
> be used for all repos on the server, either on or many, if it can be setup to
> do so.
By instance I assume you mean it in the executable sense. My first thought is to
make each repos a schema/user in Oracle. In MySql I think they will have to be
separate DBs but multiple DBs can be served by one mysqld. Other DBs I'm sure can
accommodate this as well.
It should allow for 1 to n instances. Whats important is that the table names
don't collide and that repos getting beaten to death can be easily moved to another
instance if needed. I really want to hide the instance detail behind some sort of
connection URL like is used by JDDC and DBI. "svnadmin create" a little tricky as
it will require more input than a simple URL. I'm betting there is some sort of
XML standard for DDL but I haven't checked yet. But it's too soon to worry about
those details. Right now I'm focused on how to Slide SQL into the mix without
impacting the current development too much.
I don't want to have my work punted to post 1.0 if I can avoid it.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Mark <cm...@yahoo.com>.
--- Eric Gillespie <ep...@pretzelnet.org> wrote:
> I have seen this stated a few other places, but i don't understand
> it. I am currently managing multiple projects in one repository,
> the same way i did in CVS. It works quite well, and i'm sure there
> are advantages i haven't thought of to having them share the same
> database back-end (i imagine this will become even more valuable
> when a SQL back-end becomes available).
>
> I don't want to deal with separate repositories, and i probably
> won't be the only one. What makes you think this behavior opposite
> to that of CVS users will become common?
I am not up to speed on subversion triggers or access contol mechanisms yet,
but I am current managing about 25+ (growing to 50-60 by year end) CVS non-root
pserver repositories on one server. I do this to easily control access to
individual projects, control branch access on individual projects, prevent user
manipulation of CM tags and prevent user UNIX level access to the physical
repository on the server. I can setup the same triggers scripts for all
repositories that read repository specific info/config files to use on policy
enforcement for that project.
I have not had a chance to look into subversion's ablilty to be used as a CM
tool (as opposed to just a version tool used by the open source community) and
its ability to provide triggerable actions for scripts to do CM stuff, but I
would hope it at least allows the CM process level I have on CVS. I am not sure
how atomic commits and related log info from one project will fair as part of
every other projects repository and history. I am looking at the atomic commits
as a comparible feature to ClearCases UCM. A commit being a change set. Not
perfect, but if you try UCM and know its implemetation of change sets,
subversion might not be that far off from perfect when it comes to change sets.
I am sure I am not making much sense (its late, if I'm losing you please read
on I think I have a good point or two below), but when I take over projects
that have had a developer managed CVS repository, I usually break out projects
into their own CVS repos under CM.
It might be that the developer managed repos tend to collect all projects and
the CM managed repos separate them, I guess its how you plan to use the tool
and which method best meets your needs or is the path of least resistance.
However, I see projects come and go. It would be good to be able to cut the
project that is inactive/obsoleted/replaced/canceled or whatever onto CD and
remove it from the server. Or if the project gets transfered to another group
in the company, to be able to transfer the repository would be essential. So
there are reasons for having separate repos for separate projects.
As for the SQL backend, it would be good if the same instance of the DB could
be used for all repos on the server, either on or many, if it can be setup to
do so.
> I don't think cross-repository modules will be as important as you
> think, but if i am wrong there is still a better way to handle it
> than text files.
It might be nice to have a tools repository that is setup to be checked out
with individual project repositories (different projects may be at different
versions of tools, so would have to be linked by tag). Currently this lacking
feature causes projects to store needed tools inside their individual repos.
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Stein <gs...@lyra.org> writes:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
> we're have a separate SVN repository for each project. I think the projects
I have seen this stated a few other places, but i don't understand
it. I am currently managing multiple projects in one repository,
the same way i did in CVS. It works quite well, and i'm sure there
are advantages i haven't thought of to having them share the same
database back-end (i imagine this will become even more valuable
when a SQL back-end becomes available).
I don't want to deal with separate repositories, and i probably
won't be the only one. What makes you think this behavior opposite
to that of CVS users will become common?
> As a result, cross-repository "modules" are quite important for SVN. It also
> means that when the ASF switches over to SVN, we can set up a "module" for
> Subversion that references the ASF SVN repositories.
I don't think cross-repository modules will be as important as you
think, but if i am wrong there is still a better way to handle it
than text files. If we think of the link behavior i previously
proposed as a hard link, we can think of a symbolic link as a sort
of link the client *does* have to concern itself with.
That is, a link appears identical to a file or directory and the
client goes about its business. Just as hard links are confined
to a single physical filesystem in Unix, this link is confined to
a single repository. A symbolic link, on the other hand, can point
to an external resource. So the client sees that you are committing
to two files, one here in this directory for repository A, and
another here in this symlink for repository B. It sends the changes
to the appropriate repository/server.
Unless there is something i'm missing and there's a good reason
why different projects should not share the same repository, i
won't have much interest in the symbolic link functionality, so i
would provide the original functionality i proposed first. Then,
time permitting, i might work on this second type of link.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Eric Gillespie <ep...@pretzelnet.org> writes:
>
> > You have the following nodes:
> >
> > /trunk/tools/doctools/ # directory
> > /trunk/foo/ # directory
> > /trunk/foo/foo.c # file
> >
> > svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
>
> svn ln http://foo/repo/trunk/tools/foo/ trunk/doctools/
>
> (at least that what my Unix brain wants :)
Oops, no it doesn't. You were right. Sorry.
--
Philip, who knows it's time for bed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> You have the following nodes:
>
> /trunk/tools/doctools/ # directory
> /trunk/foo/ # directory
> /trunk/foo/foo.c # file
>
> svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
svn ln http://foo/repo/trunk/tools/foo/ trunk/doctools/
(at least that what my Unix brain wants :)
>
> Now you have:
>
>
> /trunk/tools/doctools/ # directory
> /trunk/foo/ # directory
> /trunk/foo/doctools # link to /trunk/tools/doctools/
> /trunk/foo/foo.c # file
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Bill Tutt" <ra...@lyra.org> writes:
> So, if you want links, I'd highly recommend doing the symbolic link
> approach first. They fit much more nicely into SVN's data model, don't
> have issues when people create a branch (since they can be
> path-relative), and are certainly much easier to implement.
I think you misunderstand, or perhaps VSS's implementation was
poorly thought out. Let's look at it in the Unix filesystem first.
You have three files, foo, bar, and baz. foo is a regular file,
bar is a link, and baz is a symbolic link. You 'cp foo bar baz
quux' where quux is a directory. Then you echo a bit of text to
the end of each file in quux. With foo and bar (the regular file
and hard link, respectively), the originals have not been modified.
With baz, the original has been modified (assuming it pointed at
an absolute path, of course).
That's exactly how i see svn's links working (at least hard links,
as i've said, i'm not terribly interested in soft links). Now
let's see how this works in svn:
You have the following nodes:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/foo.c # file
svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
Now you have a link (called doctools) in foo. After a few months
of work, you 'svn cp trunk/foo/ branches/foo/foo-2.0'. Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools/ # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
/branches/foo/foo-2.0/doctools/ # *copy* of /trunk/tools/doctools/
/branches/foo/foo-2.0/foo.c # *copy* of /trunk/foo/foo.c
Committing in doctools on the branch affects no other copies. Note
that no one dereferenced the link, just as in the Unix filesystem.
That's just the nature of hard links; they exist in directory nodes,
not file nodes.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn modules (was Re: Features and release dates)
Posted by Bill Tutt <ra...@lyra.org>.
I'm not particularlily happy about VSS's sharing concept. The concept
tends to break down when you want to create a branch in VSS. VSS's
sharing concept maps to a hard link concept in SVN's filesystem. Due to
SVN's filesystem schema, and it's O(1) copy behavior creating a branch
that contains a hardlink will not always produce a result that makes
sense. Especially if the hard link isn't tied to just one point in time.
(The new NodeID PK mechinism, and how it interacts with NodeID concepts
makes hard links spanning repository revisiions more difficult.)
So, if you want links, I'd highly recommend doing the symbolic link
approach first. They fit much more nicely into SVN's data model, don't
have issues when people create a branch (since they can be
path-relative), and are certainly much easier to implement.
Bill
> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Wed, May 01, 2002 at 04:40:16PM -0500, Eric Gillespie wrote:
> >...
> > I don't like the text-file based modules. CVS does that and it
> > drives me nuts. Subversion doesn't really need to duplicate this
> > feature. All that is necessary is a kind of symlink in the repo.
>
> Unfortunately, symlinks in the repo aren't enough. I believe that
> Subversion
> will be more multiple-repository-prone than CVS. As an example:
>
> The ASF has one CVS repository, which contains modules for each
project:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I
> believe
> we're have a separate SVN repository for each project. I think the
> projects
> will want their own directory organization (trunk, branches, tags,
> whatever)
> and their own (partitioned) set of log messages / revision changes.
>
> As a result, cross-repository "modules" are quite important for SVN.
It
> also
> means that when the ASF switches over to SVN, we can set up a "module"
for
> Subversion that references the ASF SVN repositories.
>
> The strategy for modules, as outlined in the issue, easily supports
> cross-repository modules.
>
> >...
> > This is more general-purpose and much more flexible than modules.
> > What does everyone think?
>
> Hard and soft links in the repository will be extremely handy. As long
as
> your patches for implementing them come in digestible chunks, then I
don't
> see any obvious reason that we would /not/ include them before 1.0.
Even
> if
> you don't get them all done by 1.0, we could still include partial,
> incremental support for links.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 01, 2002 at 04:40:16PM -0500, Eric Gillespie wrote:
>...
> I don't like the text-file based modules. CVS does that and it
> drives me nuts. Subversion doesn't really need to duplicate this
> feature. All that is necessary is a kind of symlink in the repo.
Unfortunately, symlinks in the repo aren't enough. I believe that Subversion
will be more multiple-repository-prone than CVS. As an example:
The ASF has one CVS repository, which contains modules for each project:
httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
we're have a separate SVN repository for each project. I think the projects
will want their own directory organization (trunk, branches, tags, whatever)
and their own (partitioned) set of log messages / revision changes.
As a result, cross-repository "modules" are quite important for SVN. It also
means that when the ASF switches over to SVN, we can set up a "module" for
Subversion that references the ASF SVN repositories.
The strategy for modules, as outlined in the issue, easily supports
cross-repository modules.
>...
> This is more general-purpose and much more flexible than modules.
> What does everyone think?
Hard and soft links in the repository will be extremely handy. As long as
your patches for implementing them come in digestible chunks, then I don't
see any obvious reason that we would /not/ include them before 1.0. Even if
you don't get them all done by 1.0, we could still include partial,
incremental support for links.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> > If I do not want to use doctools main trunk version, but a bug fixed and
> > stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> > then?
>
> Well, in Subversion a "tag" is simply a cheap copy, so
>
> svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
Oops, that should be
svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ doctools
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Zack Weinberg <za...@codesourcery.com> writes:
> So suppose I lay out the merged repository like so:
>
> repo/complete/gcc
> gdb
> binutils
> libiberty
> ...
> gcc/trunk/gcc == ../../../complete/gcc
> libiberty == ../../../complete/libiberty
> gdb/trunk/gdb == ../../../complete/gdb
> libiberty == ../../../complete/libiberty
>
> Then I want to be able to 'svn cp' gcc/trunk to gcc/3.1-branch, check
> in patches to gcc/3.1/gcc/whatever.c, and have whatever.c record a
> proper branch in its per-file history.
>
> I also want to be able to check out repo/gcc/3.1.0-release,
> repo/gdb/5.1.1-release, repo/binutils/2.12.4-release, all into the
> same directory, have something sensible happen with files that are
> shared between the threee, and then do "svn up" later and have each
> subset of files track the branch it was checked out from. You try
> this with CVS and directories that are shared between the branches
> tend to get confused which branch you want them on.
Well, Subversion doesn't support checking-out multiple URLs into the
same directory. So you can't do
svn co .../repo/gcc/3.1.0-release -d wc/
svn co .../repo/gdb/5.1.1-release -d wc/
I don't know if there are any plans to change this. The admin file
wc/.svn/entries stores the URL used to checkout the directory, and at
present Subversion pretty much assumes that the directory has a single
URL.
You may be able to use the switch command to get what you want,
something like
svn co .../repo/complete -d wc/
cd wc/gcc
svn switch .../repo/3.1.0-release
cd ../gdb
svn switch .../repo/5.1.1-release
perhaps?
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Zack Weinberg <za...@codesourcery.com>.
On Wed, May 01, 2002 at 11:26:37PM +0100, Philip Martin wrote:
> > > This is more general-purpose and much more flexible than modules.
> > > What does everyone think?
> >
> > If I do not want to use doctools main trunk version, but a bug fixed and
> > stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> > then?
>
> Well, in Subversion a "tag" is simply a cheap copy, so
>
> svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
Let me ask a related question. This is going to require a fair bit of
context, please bear with me.
The GNU toolchain projects (GCC, GDB, binutils) are seriously
considering moving to Subversion once it has enough functionality and
stability. Currently GCC has one CVS repository, and GDB+binutils+a
bunch of other stuff share another. However, notionally it's all one
big source tree, and there are a lot of files which are shared between
the two repositories.
It would be sensible to merge the two when we switch to Subversion -
the basic reason it hasn't been done already is that it's considered
too risky. However, we want to do this in a way that lets people keep
working the way they have been. One key issue with that is the
ability to tag just a subgraph of the file tree. We want people who
check out the GCC 3.1 release label to get nothing but GCC 3.1; if
they got anything more, they might incorrectly think that the rest of
the software had been through a proper QA cycle when it hadn't.
So suppose I lay out the merged repository like so:
repo/complete/gcc
gdb
binutils
libiberty
...
gcc/trunk/gcc == ../../../complete/gcc
libiberty == ../../../complete/libiberty
gdb/trunk/gdb == ../../../complete/gdb
libiberty == ../../../complete/libiberty
Then I want to be able to 'svn cp' gcc/trunk to gcc/3.1-branch, check
in patches to gcc/3.1/gcc/whatever.c, and have whatever.c record a
proper branch in its per-file history.
I also want to be able to check out repo/gcc/3.1.0-release,
repo/gdb/5.1.1-release, repo/binutils/2.12.4-release, all into the
same directory, have something sensible happen with files that are
shared between the threee, and then do "svn up" later and have each
subset of files track the branch it was checked out from. You try
this with CVS and directories that are shared between the branches
tend to get confused which branch you want them on.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Nicklas Larsson <ki...@lysator.liu.se> writes:
> > Let's look at how this would work:
> >
> > svn co http://foo/repo/trunk/foo/
> > cd foo
> > svn ln http://foo/repo/trunk/doctools/ .
> > svn ci
> > svn up # at this point the doctools directory becomes populated
[snip]
> > This is more general-purpose and much more flexible than modules.
> > What does everyone think?
>
> If I do not want to use doctools main trunk version, but a bug fixed and
> stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> then?
Well, in Subversion a "tag" is simply a cheap copy, so
svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Nicklas Larsson wrote:
>> This is more general-purpose and much more flexible than modules.
>> What does everyone think?
>
> If I do not want to use doctools main trunk version, but a bug fixed
> and stable version (tagged with DOCTOOLS_STABLE), how should I
> create the link then?
I believe there are no tags in subversion. A tag is a copy of the tree
under another path.
So, just linking looks very nice to me, if it's implementable - I was
personally thinking just a similar kind of thing.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Nicklas Larsson <ki...@lysator.liu.se>.
On Wed, 1 May 2002, Eric Gillespie wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Actually, modules just got a whole lot closer. See recent changes to
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=517
> >
> > Anyone feel like taking it on?
>
> A co-worker and i have been kicking around the idea of writing code
> for symlinks in the repository for internal use (we're anxious to
> dump CVS :). We would of course contribute the patch, but i figured
> you wouldn't take it until after 1.0. Since it sounds like you
> might, let me describe the approach we were planning and see what
> you think.
>
> I don't like the text-file based modules. CVS does that and it
> drives me nuts. Subversion doesn't really need to duplicate this
> feature. All that is necessary is a kind of symlink in the repo.
> Clients don't even know that something is a link; they see only a
> file or directory (whatever the link points to). We'll probably
> want some way for the client to discover if a node is a link or
> not (the user might want to know for example), but under normal
> operation the client neither knows nor cares.
>
> Let's look at how this would work:
>
> svn co http://foo/repo/trunk/foo/
> cd foo
> svn ln http://foo/repo/trunk/doctools/ .
> svn ci
> svn up # at this point the doctools directory becomes populated
>
> # How many copies of the GPL do you have in your CVS repo? :)
> svn ln http://foo/repo/trunk/licenses/BSD COPYING
>
> When committing to a link, the client behaves as it always has.
> But the ra layer knows this is a link and performs the action on
> the link target.
>
> This is more general-purpose and much more flexible than modules.
> What does everyone think?
If I do not want to use doctools main trunk version, but a bug fixed and
stable version (tagged with DOCTOOLS_STABLE), how should I create the link
then?
// Nicklas Larsson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org