>
> Idea: This can be solved in the following way:
> Instead of excluding reflected revisions, the original reflected
> revisions
> are un-merged in reverse order before doing the requested merge.
>
> branch-wc$svn merge -c10 ^/trunk
> -> (trunk,10) is added to mergeinfo of branch
> branch-wc$make changes (e.g. confliction resolution) to branch-wc
> branch-wc$svn commit
> -> r20
> trunk-wc$svn merge -c20 ^/branch
> -> Instead of excluding c20, this would first merge c-10, and then
> merge r20
> so that it effectively merges the conflict resolution changes only.
Yes, your idea looks like a possiblity. But currently I am not in favour
of it for 2 reasons.
* Reverting local changes to make successful forward merge looks like a
*hack*.
* It is different from our normal way of solving 'repeat
merges'(excluding the merged revs).
>
> Then, if I am not wrong,
> trunk-wc$svn merge ^/branches/mergeinfoless-copies
> would be (assuming no conflicts) basically equivalent to
> trunk-wc$svn merge ^/trunk@LAST-SYNCED-REV
> ^/branches/mergeinfoless-copies
Yes. But it does not track the merges, it is one of the round abouts
available for issue 2897.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 16:31:41 2007