Ok - so between Ulrich and Andy I think I have these options...
1) Stick with my sym links, which I'm not keen on. There will soon be
people using windows machines involved with the project, and there's no
way of the repository of a project to 'know' about its required
libraries
2) Use svn copy which I'll play with, if nothing else looks generally
handy
3) Externals looks like its trying to do what I want
4) In the page after externals in the redbean book, there was a chapter
on vendor branches. Looked more involved that Externals, but I wonder if
it would do a better job? Any thoughts?
Thanks for your replies
Glenn
On Thu, 2004-06-03 at 01:07, Ulrich Eckhardt wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 2 18:16:26 2004