Karl Fogel wrote:
> I'm CC'ing the dev@ list here because I think the others working on
> sparse-directories should see this response. You raise an interesting
> question (see "Longer term" below folks), and although my initial
> instinct is that this shouldn't be part of sparse-directories support,
> I'd like to see what others think.
> 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. 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.
I agree with this definition of what sparse-directories is and should be.
If you wish to create a sparse copy, you can still use sparse-directories to
assist in this, but it takes just a little more effort. (You need to do a
full checkout of the pieces you want to keep, with a depth-zero checkout of
any "limbs" you wish to "prune"; schedule those to-be-pruned limbs for
deletion, then do a wc-to-repos copy.) Or, ask Karl points out, you can use
MUCC, issuing the copy + all the pruning deletions you need in a single
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Apr 19 15:54:19 2007