Question about how to handle long running branch that needs trunk updates

[Allen Servedio <al...@yahoo.com>]

I apologize ahead of time if this is in a FAQ somewhere. If so, please let me know where I can find it as I imagine this has come up before since there is an issue for it.

As it appears that issue 2897 (http://subversion.tigris.org/issues/show_bug.cgi?id=2897) [reflective merging] will not be going out with Subversion 1.5, I thought I would ask if there was a way to handle the situation below (because we were planning on using reflective merging for this):

We have long running projects (anywhere from 1 to 6 months for example) that add to the trunk code when they are done. While they are under development they typically need updates from the trunk code so that they can continue working properly with external systems and/or to get features or bug fixes that they also need to integrate with or to function properly. The reason that they are typically in a branch is that they may be aborted and/or they may take a long develop/test cycle that living in the trunk would not allow (since we release trunk every two weeks with bug fixes and new projects).

How do people handle conditions like this?

If reflective merging was supported, here is how we would have done this:

1) Branch from trunk to create project branch proj1
2) Commit some changes in trunk and merge them to proj1
3) Commit some work to proj1
4) Repeat steps 2 and 3 a couple of times (in any order and number of times)
5) (THIS IS THE BIT NOT CURRENTLY SUPPORTED) The project is complete, so merge proj1 back to trunk

This is basically what (if I understand it correctly) issue 2897 will allow you to do.

Thanks!
Allen
       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

Re: Question about how to handle long running branch that needs trunk updates

[Allen Servedio <al...@yahoo.com>]

I don't think we had looked at SVK, but we had originally looked at svnmerge.py. I
think that we had not used it originally simply because we were just starting to
use Subversion and did not understand that we would need svnmerge.py to try to
do what we were doing (just naive newbie users).

I see that there is a conversion script when 1.5 comes out for svnmerge.py, so
that makes it appealing to try to start using now
(http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/svnmerge-migrate-history.py).

Thanks for the feedback!
Allen

John Peacock <jo...@havurah-software.org> wrote: Allen Servedio wrote:
> How do people handle conditions like this?

Use SVK?  I've used this extensively to manage private branches of 
public projects (like Subversion).

Or you could use svn-merge.py?  This will notate the merge history and 
produce the minimal changeset required to merge the branch back into 
trunk without duplicate merges (AIUI).

HTH

John

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



       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

Re: Question about how to handle long running branch that needs trunk updates

[John Peacock <jo...@havurah-software.org>]

Allen Servedio wrote:
> How do people handle conditions like this?

Use SVK?  I've used this extensively to manage private branches of 
public projects (like Subversion).

Or you could use svn-merge.py?  This will notate the merge history and 
produce the minimal changeset required to merge the branch back into 
trunk without duplicate merges (AIUI).

HTH

John

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

Re: Question about how to handle long running branch that needs trunk updates

[eg <eg...@gmail.com>]

Allen Servedio wrote:
> I wonder about this. Will it really do what the documentation says so 
> long as
> issue 2897 is unresolved
> (http://subversion.tigris.org/issues/show_bug.cgi?id=2897).
> 
> My understanding of that issue was that so long as it was
> unresolved, things like --reintegrate would not work for our use case.
> 
> Am I wrong on this? Because the documentation makes it sound like it does
> exactly what we were looking for.
> 

First to clarify... I am not an expert in the current state of the merge 
tracking dev effort in 1.5. Just an interested observer who has been 
lurking and listening and trying to understand what is happening.

There is a big long discussion thread on the dev list which, amongst 
other things, tries to clarify these differences.

The following link jumps you to the middle of the discussion where 
someone tries to summarize the difference between the "-reintegrate" and 
"issue 2897" use cases for merge tracking:

http://svn.haxx.se/dev/archive-2008-01/0198.shtml


Hope this is helpful.

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

Re: Question about how to handle long running branch that needs trunk updates

[Allen Servedio <al...@yahoo.com>]

I wonder about this. Will it really do what the documentation says so long as
issue 2897 is unresolved
(http://subversion.tigris.org/issues/show_bug.cgi?id=2897).

My understanding of that issue was that so long as it was
unresolved, things like --reintegrate would not work for our use case.

Am I wrong on this? Because the documentation makes it sound like it does
exactly what we were looking for.

Thanks,
Allen

eg <eg...@gmail.com> wrote: Allen Servedio wrote:

> How do people handle conditions like this?
> 
> If reflective merging was supported, here is how we would have done this:
> 
> 1) Branch from trunk to create project branch proj1
> 2) Commit some changes in trunk and merge them to proj1
> 3) Commit some work to proj1
> 4) Repeat steps 2 and 3 a couple of times (in any order and number of times)
> 5) (THIS IS THE BIT NOT CURRENTLY SUPPORTED) The project is complete, so 
> merge proj1 back to trunk
> 

I think this last step can be done with the -reintegrate merge option.

Read the section in the subversion book nightly build (for 1.5) that is 
in the "Common Branching Patterns" in a subsection titled "Feature 
Branches"... I think it describes your workflow.

The url is:
http://svnbook.red-bean.com/


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



       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

Re: Question about how to handle long running branch that needs trunk updates

[eg <eg...@gmail.com>]

Allen Servedio wrote:

> How do people handle conditions like this?
> 
> If reflective merging was supported, here is how we would have done this:
> 
> 1) Branch from trunk to create project branch proj1
> 2) Commit some changes in trunk and merge them to proj1
> 3) Commit some work to proj1
> 4) Repeat steps 2 and 3 a couple of times (in any order and number of times)
> 5) (THIS IS THE BIT NOT CURRENTLY SUPPORTED) The project is complete, so 
> merge proj1 back to trunk
> 

I think this last step can be done with the -reintegrate merge option.

Read the section in the subversion book nightly build (for 1.5) that is 
in the "Common Branching Patterns" in a subsection titled "Feature 
Branches"... I think it describes your workflow.

The url is:
http://svnbook.red-bean.com/


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