It would be quite nice to have a complete record of all patches
included in a merge. This would be real changeset passing. However,
this would obviously be big and start to reproduce the complete
repository. I think that cyclic merges could be improved by recording
only the edits that you make on the merge. So, if you merge r2 and r3,
make some edits, and commit them, the merge_history would show that you
merged r2 and r3, and it would include a diff, but only for your new
edits. It's worth a try. The ticket about problems with cyclical
merges specifically mentions the problem with tracking new edits on the
merged working copy.
On 7/11/2011 2:42 PM, Daniel Shahaf wrote:
Andy Singleton wrote on Mon, Jul 11, 2011 at 13:57:58 -0400:
Yes, the "cyclic merge" problem is a big one, and along with the
tree change problem, it accounts for most of the frustrating
behavior of Subversion merge -
http://subversion.tigris.org/issues/show_bug.cgi?id=2837
I believe that cyclic merges can be handled with a bigger
merge_history / merginfo file. When you do a merge, you make some
edits to resolve problems. Then, you commit the changes - all of
the merged changesets, plus the edits. You also write the
instructions
Define "instructions".
If the algorithm is
When trying to merge to branch T a patch rN from branch S, where rN
added mergeinfo identifying changes that are already present on T,
diff (the tree resulting from merging the mergeinfo-delta described
by rN to S) to S@rN and apply the resulting patch to T,
then perhaps you mean, precompute the parenthetical part at merge time
and record it somewhere in the repository...?
for resolving this merge into the merge_history /
merginfo file. The next time you go to do a merge, you can replay
any of the changes that you need. The new merge_history will be a
big file with a complete history.
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
