Diffidently, I would like to point out that most Subversion developers
consider this lack to be simply a bug -- a fixeable one, see
http://subversion.tigris.org/issues/show_bug.cgi?id=937 for some more
background.
Not that this helps you right now, Patrick, and I fully understand
your logic in not adopting a system that doesn't offer one of the
features you want. We don't currently have a convincing
CVSROOT/modules replacement, but believe me it's not because we're
unaware of the need :-). The current svn:externals feature isn't
really the same as true composition, we'd be the first to admit.
-Karl
Patrick Kelsey <pkelsey@gmail.com> writes:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 30 08:17:48 2004