...
> Correct (although if you do a co -rNNN or an update -rNNN the externals
> will still use HEAD, so not completely what you'd expect).
>
...
> (1) Partially possible using svncopy.pl from
> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svncopy.pl.in
> - you can tag and it will behave as expected (svncopy.pl --tag). To
> branch and get the behaviour you will need to branch the destinations of
> the svn:externals at the same time (i.e. in the same command).
>
> (2) Not possible at present. In fact, svn commit doesn't walk the
> externals so you have to check them in separately.
Thanks for the response, Ian.
It seems then that svn is sorely lacking a very important/powerful
feature, which I'll call Composition. Composition is the ability to
compose a working copy from disjoint parts of the internal storage
structure used by the source control system, and be able to treat that
composed working copy exactly the same as a working copy that is
obtained from a direct checkout of a part of the internal storage
structure employed by the source control system. This should all be
handled transparently by the source control system using information
contained in the repository. In other words, I should be able to
create and use a mapping between the internal storage structure of the
repository and the storage structure of my working copy, without
having to care that I am using such a mapping.
Composition is important because it allows multiple working views of
the same underlying sources. In my work, I have found this to be
extremely useful for dealing with multiple projects that have sets of
libraries in common. Without composition, you either need to do
perform a lot of steps to manually build up your working copy (and
similarly many steps to branch and tag), or maintain separate
instances of each library in the repository for each project that uses
it and constantly merge changes between them.
CVS makes composition possible via the modules administrative file,
and from the user's perspective it is transparent. For this reason,
no extra work is required on the part of the user to reap the benefits
of composition, and it works out of the box with all of the GUI tools,
so there are no working environment restrictions on using it (such as
needing to run special scripts at the command line).
We are currently using VSS, and for all the obvious reasons it needs
to be replaced. I don't see, however, why I would use subversion over
CVS. At this point, subversion seems to be more of 'just another cvs'
than 'a compelling replacement for cvs'. CVS does a good job of
source control, but it has its quirks. Unless I'm really missing
something, I don't see subversion heading to a significantly different
outcome. It'll do source control well, but it'll have its quirks. And
since one of subversions quirks is that it requires lots of extra work
to deal with multiple complex applications that share code over CVS, I
hardly feel compelled to employ it over CVS. I suppose it is pleasant
on some level to have an O(1) repository with an elegant conceptual
structure, but if at the end of the day that means all the developers
do more work, I'd rather choose the O(n) repository and let the
computers and networks spend the effort for us.
My $0.02.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 30 04:53:55 2004