glenn wrote:
> I have my a set of includes that I maintain in their own right and
> include in a number of other projects. Lets call these project A
In C terms, A would be a library, right?
> So now I want to start project B, which includes project A, but will be
> version controlled in its own right, as A is also now included in
> project C.
Both project B and C use that library, I assume.
> So when working on B, I fix a couple of bugs in B's copy of A, and
> perhaps add an enhancement, and at some point I'm going to want to
> commit these back, and update them to C, and of course vice versa.
>
> At the moment I'm keeping A in its own working copy, and using symbolic
> links, but I don't see this as a durable solution. Esp when multiple
> users and machines get involved.
I think that is exactly the right thing to do. However, you could create an
A1(svn copy...), which is version 1 of A. This thing is closed for changes,
and only bugfixes are comitted.
When adding new features while working on B or C, you will reach a point when
you want to publish these changes. You then simply create an A2 from the
current A and update docs of B and C that they require A2.
> Just to complicate things Project D, may be established, and would like
> to only inherit the bug fixes, but not the new features, and perhaps
> more dramatic changes and re-organisings of A which could de-stablise
> it.
That's why project D only uses A1. BTW: merging a bugfix that was done to A
back into A2 or A1 is something for which 'svn merge' comes handy.
There is the alternative that both project B, C and D have a private copy of
A. In some cases, that is even the easiest solution. Using 'svn merge', you
can still selectively merge in bugfixes and other enhancements, but the more
projects you have, the more maintainance work it becomes.
Also take a look at 'externals', maybe that is a better way than to keep
symlinks up-to-date.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 2 17:08:05 2004