David James wrote:
> William Waghorn wrote:
>> 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
I understand the temptation to create a repository structure like this,
really I do. I get to see this in use every day, and it even kind of
works. The problem I have with it is that the repository is *unusable*
without a viewspec. How are you going to propagate that viewspec?
Subversion shops will have to publish this viewspec somehow, and that's
just horrid.
> 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.
Branches are cheap, and offer much better control over shared
components. Obviously, merge tracking and branch specifications can
make all the difference. Changes can be taken from the Component branch
when each project is ready for them, and any local changes get merged
back only when the changes are of the required standard.
>
> 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.
What happens when 'Product 1' modifies 'foo', and accidentally breaks
its compatibility with other projects? I note that this has been
discussed more eloquently elsewhere in the thread.
>
> 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.
Ok. So, where exactly does the viewspec get stored? I know you said
'.svn/entries', but in the project root, or is it distributed? Can you
still run 'svn update' in a subdirectory while still honouring the viewspec?
William
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 17 02:12:58 2006