William Waghorn wrote:
> 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.
Both Perforce's client specs and Subversion's viewspecs can be
misused. However, they also can be very useful. Consider the following
repository layout, as presented by Ben Reser in [1].
components
|-- foo
|-- bar
`-- baz
products
|-- prod_1
|-- prod_2
`-- prod_3
Let's say we have the following situation:
- Product 1 needs just the 'foo' component
- Product 2 needs just the 'foo' and 'bar' components.
- Product 3 needs all of the components
If you want to checkout a product, plus its components, you have four options:
1) Checkout the full tree
2) Checkout the individual directories separately
3) Copy the components you need into each product
4) Emulate viewspecs using 'svn switch'
5) Setup a viewspec for each product
Problems with Solution #1:
If you have a very large repository, Solution #1 will require you to
perform a very large checkout.
Problems with Solution #2:
First, Subversion doesn't let you perform atomic commits across
multiple working copies. Second, if your product uses a lot of
components, every developer in your company is going to have to type a
lot of checkout commands. (Wouldn't it be great if they could automate
this work using a viewspec?)
Problems with Solution #3:
Every product has a separate branch of each component. If product #1
modifies component 'foo', they will need to merge their changes back
to the 'components' directory, and also to every other product which
uses 'foo'. Long term, this isn't maintainable.
Problems with Solution #4:
This solution works great. You can checkout the components you need
into a single working copy. You will need to type a lot of 'switch'
commands, though (one per component)! At CollabNet, we use this
solution (we wrote an automated script to perform all the necessary
'switch' operations).
Problems with Solution #5:
As with Solution #4, this solution works great. You can checkout the
components you need into a single working copy. You will probably want
to store your viewspecs for each product directly in the repository,
so that it can be shared by the developers of each product.
A simple viewspec for Product #2 (if you want to keep the same
directory structure in your tree as in the repository):
+components/foo/...
+components/bar/...
+products/prod_2/...
With this simple viewspec, a checkout of product 2 will look like this:
components/foo/...
components/bar/...
products/prod_2/...
Pretty simple, eh? It is. Still, not everybody wants that directory
structure. Some folks would love to see "Product 2" in the root
directory of their checkout, with the component directories
underneath. Using 'svn switch', you can set this up.
A complex viewspec for product #2 (relative to products/prod_2):
+...
-components/... ../../components/...
+components/foo/...
+components/bar/...
Note that the 'components' directory is marked as "-", so that new
components will not be pulled in automatically unless they are
explicitly mentioned in the viewspec. Note that Subversion does not
currently support this feature, even if you use switch.
In practice, at CollabNet, we emulate viewspecs by switching each
component directory separately. By doing this, we work around the fact
that Subversion does not support incomplete checkouts. This type of
viewspec could show up as follows:
+...
+components/foo/... ../../components/foo/...
+components/bar/... ../../components/bar/...
On 7/16/06, William Waghorn <willw@litany.me.uk> wrote:
> > 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?
No. However, if a directory is marked "-...", it doesn't mean that a
child directory is not actually present. For example, in example #1
(quoted below), the root directory is implicitly marked as "-...", but
foo/images is still in the working copy.
> > EXAMPLE #1: Download only foo/images and bar/images
> >
> > +foo/images/...
> > +bar/images/...
> > REFERENCES
> >
> > [1]: Ben Reser's proposal
> > http://svn.haxx.se/dev/archive-2005-07/0398.shtml
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 16 19:22:04 2006