[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