Controlling 1 projects included in another

[glenn <gd...@tpg.com.au>]

Hi All

Bad subject, but didn't know how to phrase it.

I'm looking for some clear thinking about how I should approach this
situation. Many of you must have been here before me.

In this scenario:

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

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.

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.

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.

Please, can any one suggest how I can tackle this?

Thanks 
Glenn


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Controlling 1 projects included in another

[kf...@collab.net]

Have you checked out the 'svn:externals' property at all?  We use it
for similar things.  See

  $ svn co http://svn.collab.net/repos/cvs2svn/trunk/

...for an example of how svn:externals is used this way.  (I don't
think it will solve all your problems, for example not the Project D
scenario, but it might help with some of your needs).

-Karl

glenn <gd...@tpg.com.au> writes:
> Bad subject, but didn't know how to phrase it.
> 
> I'm looking for some clear thinking about how I should approach this
> situation. Many of you must have been here before me.
> 
> In this scenario:
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Please, can any one suggest how I can tackle this?
> 
> Thanks 
> Glenn
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Controlling 1 projects included in another

[glenn <gd...@tpg.com.au>]

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

Re: Controlling 1 projects included in another

[Ulrich Eckhardt <ec...@satorlaser.com>]

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