[Svnmerge] Remembering conflict resolutions to avoid double manual resolutions

[Raman Gupta]

Micah Elliott wrote:
> I have a simple use case that seems very common, but doesn't work
> with svnmerge:  1) A developer is merging changes from trunk to his
> branch, and a conflict occurs.  He resolves it in favor of his
> branch's version.  Then 2) he merges his branch back to trunk and
> *the same conflict has to be resolved again*.
> 
> Why isn't there some ability to record that he has already
> resolved this same conflict?  (I can share my thoughts on how to
> approach a solution to this, but for now I'm just asking in case
> this is a pilot error on my part.)

There isn't because nobody has yet come up with an elegant way to do
this within the confines of svnmerge. If you have some ideas, please
do post them to the list.

> I'm not sure what the technical name is for this ability.  I
> thought it was "reflection", but svnmerge appears to use that
> name in a different way.

The term "reflection" in svnmerge refers to the entire revision,
including the conflict resolution changes. So, if I merge rev 5 from
trunk to branch and that is rev 6, and then create rev 7 on the branch
and merge back to trunk, rev 6 is "reflected" and only rev 7 is merged
to trunk (assuming -b flag is set).

> This was touched on briefly before in this thread:
> 
>     http://www.orcaware.com/pipermail/svnmerge/2007-February/000857.html
> 
> And the answer basically was:
> 
>     "it seems that the conflict will have to be resolved manually
>     for both merges ... and with the current design of svnmerge,
>     this cannot really be fixed."
> 
> [snip]
> 
> Is there a good reason that this can't be implemented/fixed in
> svnmerge.py for some/most merge situations?

Solving this seems to require tracking extra information about merges
that cannot be easily stored within merge properties, which is how
svnmerge.py currently operates. I think there was quite a bit of
discussion on svn-dev about how to track this information in svn 1.5.
Some of the solutions involved internally creating separate commits
for the real reflected changes, and for the conflict resolution
changes. There were some other solutions also, but IIRC all involve
some relatively major backend/schema changes.

Cheers,
Raman Gupta