David James wrote:
> It's often true that users want to checkout some, but not all, of a
> large repository. Currently, it's easy to checkout a single subdirectory
> using Subversion. However, if you want to checkout a group of
> subdirectories, and manage this group as a single working copy, you're
> going to run into some major challenges.
>
> In the past year, we've seen two proposals for managing large working
> copies. Last year, Ben Reser proposed creating two new subcommands,
> called 'svn include' and 'svn exclude', which allow you to configure
> which directories are pulled in by 'svn update' [1]. This year, Eric
> Gilespie proposed to instead add a depth parameter to the 'update'
> command [2].
>
> Both Ben and Eric's proposals suffer from a similar problem: they don't
> actually make it easy to checkout a group of subdirectories. With either
> proposal, you're forced to execute a long series of commands (or a long
> series of options) in order to check out a group of subdirectories as a
> single working copy.
>
> I'd like to propose we add full-fledged viewspecs to Subversion. Here's
> how such a feature might work:
Perforce has viewspecs, indeed with a syntax uncannily similar to that
you've
proposed.
Actually, Perforce is pretty much built around the concept of
viewspecs (Perforce calls them client specs or workspace specs). It needs
this functionality. Subversion does not. IMHO it is one of those features
which may sound like a good idea at the time, but which you will later
regret.
The problem comes from the temptation to use viewspecs as an excuse for not
fixing a poorly organised repository layout. Add in mapping directories to
alternative locations, and things can get really chaotic.
> ===================================================================
> REORGANIZING TREES USING VIEWSPECS
>
> In some cases, users will want to reorganize their tree to have a
> different structure from the one in the repository. Currently,
> users can reorganize their trees using switch. I'd like to allow
> users to also be able to save and restore this kind of reorganization
> using a viewspec.
This is very definitely a feature worth avoiding. Users should never
*need* a viewspec definition to be able to use a repository effectively,
and that's exactly what this feature will engender. Perforce users
often suffer from this, and would suffer a good deal more if the
viewspecs weren't stored on the server (i.e. the '-t' option for 'p4
client').
Also, its not clear how your proposal intends to implement this
functionality.
> NOTE:
>
> When traversing the working copy, 'svn' will still need to recurse into
> subdirectories which are marked "-...". This marker simply indicates
> that child entries are excluded by default. If the directory exists
> in your working copy, and a nested file or directory is marked as
> included, the most deeply nested marker takes priority.
Are you suggesting the directory tree is always checked out, even if the
files they contain are not?
William
ps. Baggage alert: I use Perforce by day, and have a reputation for
non-stop whinging about it amongst my colleagues. While I respect
Perforce's implementation of viewspecs, I dislike the concept in
general. I also feel their command line UI is downright user-hostile.
Take everything I've said with a generous pinch of salt.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 16 14:33:48 2006