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
_______________________________________________
Svnmerge mailing list
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
