[Svnmerge] Two-level branching

Oefelein, Martina Martina.Oefelein at dionex.com
Fri Jun 15 03:25:40 PDT 2007


Hi all,
 
I'm looking for a good solution for the following scenario:
 
I have a project that is based on a relatively old compiler. I want to port the project to the newest version of the compiler. This requires many changes due to stricter checking, outphased constructs etc. A large portion of the porting issues is caused by a certain library, which causes many spurious errors with the new compiler. So my approach was first to port to a newer version of this library that is compatible with both the old and the new compiler, then to port to the new compiler. So I set up the following branch structure:
 
           /-------------> B2: Port to new compiler
          /
    /-------------> B1: Port to new library
   /
-----------------> trunk
 
Both ports are incomplete, as I'm only porting these parts that I need at the moment, so these branches will continue to exist for an extended period of time. Meanwhile, there is still a lot of development on trunk that I want to merge into both branches.

I came up with several approaches:

Method a: Merge from trunk to B1, then from B1 to B2
Method b: Merge changes from trunk separately to B1 *and* B2, merge porting changes in B1 to B2.
Method c: Ignore B1 for the most part, and merge only directly from trunk to B2. Only if there is a problem with the library while merging to B2, merge this part first to B1, port to the newer library, then merge them to B2.

Method a seems to be the most straightforward, however, I'm concerned what happens if a change in trunk merges cleanly to B1, but can't be applied to B2:

I plan to run svnmerge.py merge just every few weeks to merge all available changes from trunk, so there might be hundreds of revisions that I merge to B1 in one commit. Now if one of these can't be applied to B2, I can't block this one change, because svnmerge sees only one big commit in B1. Thus I would have to resolve the conflicts manually in B2. Or is there a way to avoid this?

So I thought, method b would maybe better, because svnmerge would now be able to see all commits individually, and I can block them as needed. But I would have to juggle with merging changes from two sources to B2. How good does svnmerge handle this?

The idea behind method c is that I won't ultimately need B1 as it is only a means in getting to B2. But this is even more complex, and I'm still new to svnmerge...

Suggestions? Has anybody experience with such a two-level branch merging scenario?

ciao 
Martina 



                                                                                                                  
Dionex Softron GmbH
Rechtsform: Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Germering
Geschäftsführer: Dr. Peter Jochum
Zuständiges Registergericht: Amtsgericht München, HRB 717 65





More information about the Svnmerge mailing list