[Svnmerge] Multi-directional merges with multiple branches
Steven Shanks
sshanks at valleyt.co.uk
Thu Oct 26 06:22:22 PDT 2006
Hi,
I have recently added another branch to one of my Subversion
repositories, so it now looks like this:
repos/trunk
repos/branchA
repos/branchB
Both of the branches and the trunk are considered "current", and so I am
attempting to keep track of bug fixes etc between all three versions. I
have set up svnmerge.py as follows:
[trunk] svnmerge.py init [branchA]
[trunk] svn commit
Revision 100 committed.
[trunk] svnmerge.py init [branchB]
[trunk] svn commit
Revision 101 committed.
[branchA] svnmerge.py init [trunk]
[branchA] svn commit
Revision 102 committed.
[branchB] svnmerge.py init [trunk]
[branchB] svn commit
Revision 103 committed.
However, I'm not sure this is the right way to go about this,
particularly when it comes to blocking revisions. Say I make some
changes in branchB and commit them:
[branchB] svn commit
Revision 104 committed.
Obviously, this revision should now be available in trunk:
[trunk] svnmerge.py avail -b -S [branchB]
104
But for whatever reason, I decide that this fix only belongs in branchB:
[trunk] svnmerge.py block -r104 -S [branchB]
[trunk] svn commit
Revision 105 committed.
This solves the problem for trunk, but now I will have another revision
available for branchA:
[branchA] svnmerge.py avail -b
105
If I block this revision (105) in branchA, then svnmerge.py will
recognise that this was a bi-directional block, and the problem will
disappear, but I have now had to block several revisions after
committing one. If it became necessary to add a third or fourth branch
to this setup, then the problem only increases.
Does anyone have any suggestions on how I might avoid this problem, or
ways I could change my setup to minimise it?
Thanks for any help, and apologies for the length of this post!
Cheers,
Steve
More information about the Svnmerge
mailing list