Hi Patrick,
> > 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/svnc
> opy.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).
I've been thinking about this since your mail. It should be possible to
update the script so that it walks the externals itself on the branch.
I'll work on that when I get a few round tuits.
> > (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.
I agree the support for composition isn't great (yet), but Subversion is
being actively worked on and it will get there. For me, the compelling
features of Subversion over CVS are the atomic commits and the fact that
it can manage directories, copies and moves properly. I always hated
the fact that if I wanted to move things around in CVS I had to actually
muck about in the repository (and then lost the history, and couldn't
reconstruct an old version - VSS also has this problem).
If you are currently a VSS shop and are moving to something else, I
would seriously recommend you don't shift to CVS now. Either make the
shift to Subversion now and live with the poor composition support until
it gets better, or wait and make the shift once it is supported.
Otherwise you'll have to disrupt all the developers again once you shift
from CVS to Subversion.
Alternatively, you could shift now and help get the composition support
added - it's open source, after all. That's how svncopy.pl got
developed - it was hurting us so I wrote the script and submitted it.
BTW I have no attachment to Subversion other than using it (mostly
happily).
Cheers,
Ian Brockbank
Applications Software Team Leader
e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
scd: ian@scottishdance.net
t: +44 131 272 7145
f: +44 131 272 7001
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 30 11:57:02 2004