Jeremy Pereira wrote:
> Unfortunately, it's not glaring at me. What would this feature be for?
Glaring might be overstating it a bit. The typical use case where
cloaking came in handy was larger project structures where a user really
doesn't want or need all of the repository downloaded to their hard
drive. In VSS land, you typically created a single repository for the
entire development team, then had sub-folders for each project (possibly
with another layer above that to group projects by client).
Let's go with the simple case and say that a developer is working on
project A, B, D and F for a particular client. In order to make life
simple, they would cloak C, E and G so that they could do a "get latest"
(similar to "svn update") at the customer level which would then update
their local working copy for all 4 projects.
In the SVN world, they have to individually do updates separately on A,
B, D and F project folders, or simply bring down projects C, E and G as
well. (Or they could write a batch file to do "svn up" in each project
folder...)
It's always been a client-side setting (developer B won't want the same
cloaks as developer A) in the VSS world. It's more of a convenience
feature then part of the development process, but it makes working with
large and complex repositories a lot easier.
I can envision that some users would even like the ability when doing a
checkout to say "cloak all sub-folders by default". Then they can pick
and choose which folders to bring down locally. (But that's a "far out"
use case and not very typical.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 3 21:02:24 2006