David James wrote:
> 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 #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.
I strongly disagree with this statement, especially as things scale up.
What it *is* fully unmaintainable is that a commit made to compent 'foo' by
a developer of Product 3 (in New Zealand) breaks Product 1 (and its team in
New York) the day before its deadline, because the developer of Product 3 is
not even aware of the existence of Product 1, let alone knowing Product 1's
workplan, milestones, or how to perform a comprehensive test of 'foo' within
Product 1 to validate the commit. And if there are 100 Products using
component 'foo', would you request a developer of Product 34 who wants to
commit a modification to 'foo' to test the other 99 Products to make sure he
is not breaking anything?
The only way this scenario can really scale up is through usage of branches.
If Product 1 has a local branch of compenent 'foo', developers of Product 1
can freely bugfix/enhance/modify the component, without incurring the risk
of breaking products and teams they are not even aware of. It's then up to a
thrid entity, called "The foo maintainer" to merge the local 'foo' within
Product 1 into the "official" foo trunk. The teams working in Product 1/2/3
can then merge changes from foo's trunk into their local changes whenever
they see fit (based on their own needs, schedules, and phase of the moon).
What should be said, instead, is that Solution #3, whilst representing the
overall best theoretical solution, requires too much overhead (especially
with Subversion's primitive merge support and the absence of branch
management tools) which many smaller teams/projects will not want to pay
for. Viewspecs represent a very feasable alternative solution, which
probably fits better smaller setups.
My humble opinion is that the scenario of shared components, depicted in
this mail, is not a very compelling case for viewspecs. Instead, I'll
eagerly buy the one suggested by the topic of this thread (managing
subportions of large trees). Please go ahead with this, I have large trees
in SVN :)
--
Giovanni Bajo
---------------------------------------------------------------------
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:42:15 2006