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 -
>> 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
> 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_at_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.
Founder/CEO, Assembla Online: http://www.assembla.com
Received on 2011-07-11 21:06:25 CEST