[Svnmerge] Experiences with svn/svnmerge; supporting tools around svn/svnmerge

[Hermanns, Horst]

Hi,

after a few months using Subversion and svnmerge we would like to
exchange our experiences.

We run into some problems and built some supporting tools around
svn/svnmerge for managing parallel development and merges between
branches.

==> many commands/steps to create branches and initialize svnmerge 
We made a little tool to do this for us. You can select Source, enter
new Target-Branch and it will execute 'svn copy' and 'svnmerge init' on
both branches.

==> merge from refactorings, possible data loss
Subversion handles moves/renames as delete followed by add. During a
merge, modifications in the target branch can get lost, because the
delete on source branch is applied to the the target branch and does not
care about prior modifications.

We made a tool to check for refactorings before a merge. Both branches
(source/target) are analyzed for moves/renames. The search is based on
the svn history and starts with revision based on corresponding property
svnmerge-integrated. We check each refactored file for changes since
last merge and display a status (M,D,-). So we can act before deleting
modified files or outputs like 'skipped missing target'.


==> handling conflicts repeated in case of bidirectional merges
==> merges in multiple revision ranges, multiple conflicts, possible
data loss

All of our Dev.-Branches are based on a BASE-Branch with bidirectional
merge relation.
 Dev1 <----> BASE
 Dev2 <----> BASE
 ...

We update our Dev.-Branches regularly from the BASE-Branch ("Rebase"
after changes in BASE). Conflicts during merge from BASE->Dev.-Branch
occur once more on a later merge back from Dev.-Branch->BASE. 
This happens because svnmerge collects all revisions with changes in
Source without taking care about earlier merges (conflicts) in the
opposite direction. In spite of periodic merges from BASE->Dev.-Branch
("Rebases") we are faced with the same conflicts based on old changes.
Additionally multiple conflicts can occur in case of extensive merges in
several revision groups. This conflicts are not easy to resolve because
with each conflict, subversion creates new conflict files (.working,
.merge-left ...) based on the ealier conflict. We also had situations
where a merge conflict was followed by some successfull merges for a
file. In this case some changes are only located in the original file.
But conflict editor tools will overwrite the original file based on the
older conflict files. If so, some information get lost.

In most cases this conflicts are not relevant anymore, because of the
"Rebase" we only want the last version of the Source-Branch. In our
example (merge Dev.-Branch->BASE) we only have to check wether there
have been changes in BASE
(Target) for the conflicted file since the last merge BASE->Dev.-Branch.
If not, we can directly use the last version of Dev.-Branch to solve the
conflict.
We also made a tool to automatically solve this sort of conflicts.


- intergration branches
Another problem are the lack of creating integration branches. For
example we have created several Dev.-Branches for different development
stages (all based on BASE with bidirectional svnmerge init).
2 Branches shall now be integrated to a new development branch and
together tested before a concluding merge to BASE (Baseline).
So for each Dev.-Branch we have to break open the merge dependencies to
BASE and relocate them to a new
Integration-Branch.

old:	                  new:
Dev1 <---->                 Dev1 <---->
            BASE                        Int1  <---->  BASE
Dev2 <---->                 Dev2 <---->

If doing so we have to take care about relected/initialized/phantom
revisions of the old merge dependencies.
We also made a tool for this. It creates the new Intergration-Branch
with merge dependecies to
BASE, relocates the merge dependencies of the Dev.-Branches to the
Integration-Branch and sets prior detected
relected/initialized/phantom revisions as blocked revisions for each
merge dependency.



End of our short story about svn/svnmerge. ;-)


Perhaps you run into similar problems or found other
solutions/approaches?
We are also interested in exchange/enhancements of supporting tools.

Anybody with experiences in subversion 1.5 and the changes to expect?

Best regards
Horst