On 4/19/07, Karl Fogel <kfogel@red-bean.com> wrote:
> Sparse-directories is purely a matter of client-side arrangement.
> It's about controlling the size and shape of the working copy a
> particular user deals with, not about making that sparse tree a
> permanently versioned object to share with others.
That makes sense as far as it goes, but I would argue that making
something permanent to share with others (whether with branch or tag
use in mind) is a very valuable form of inter-developer communication.
> For example, right
> now in a sparse working copy, 'svn update --depth=infinity' should
> expand it so it won't be sparse anymore. But if you made a sparse
> copy, and someone else checked it out, then a depth=infinity update
> wouldn't have that effect in the checked-out copy.
Which would be precisely the desired effect.
> Anyway, that's my opinion right now... if people have arguments why
> sparse copying is important, let's hear 'em. Note that it could
> always be added in a later release; it doesn't have to be on the same
> schedule as sparse directories itself.
As I suggested above, it seems very valuable and powerful to be able
to easily produce a sparse copy for sharing with fellow developers.
One example:
A large team has a trunk with, say, 100 different libraries, 100
different 3rd party components, etc. A new project/feature comes
along and is envisioned as using a handful of each of these, so a lead
developer constructs a sparse WC to pick out the right libs and so
forth, then just issues an "svn copy . <url for new branch>" and then
communicates the new branch url as the site for future work on said
project.
Is this scriptable without "sparse copies"? Sure, and for that matter
the construction of the initial "sparse" WC is largely scriptable
today with a mix of regular/non-recursive updates (1.4.3). But if the
tools make it easier, it gets done more, used more creatively, etc.
So consider that a plug for the value of copying a sparse tree. That
said, I may be missing the primary intent for sparse trees, and I'm
certain I'm missing the implementation implications.
Thanks,
Kylo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 19 19:56:33 2007