Re: [RFC] v2 Tree conflict resolver spec.

Julian Foad wrote:
> Yup. And with merge, --accept=mine should be identical to 'svn revert'.

Hey, wait a minute. That's not true when there were local modifications
before the merge. I see it like this:

Merge tree-conflicts, when they are encountered, should change neither the
checked-out nor the check-in states other than flagging a conflict and
storing some info with it.

--accept=mine should then simply remove the conflict marker and done.

--accept=theirs should be identical to 'revert' plus pulling in 'their'
changes into the check-in state. In other words, --accept=theirs should
reset the check-in state to the incoming action. The info stored with the
conflict must somehow convey the incoming action. Oh my, *that's* the hard
part ;)

Or am I twisting things now?

I am thinking incrementally with merge. Local mods are allowed to exist
before the merge, and I want to be able to go back to exactly those with
--accept=mine.

That's simple enough for a two-URL merge. But for a number of partitioned
revision ranges (e.g. with a --reintegrate), that may be a problem. What if
only the third or fiftieth revision range that is merged causes a tree
conflict? Does merge combine them before passing the resulting changes to
the merge_editor? Either case, recording or indicating those changes in
tree-conflict information is a tricky question on its own...

Have I left orbit?

Still, I think it's quite insane to equal --accept=mine with a *revert*, of
all things :) Revert *loses* mine, which is dangerous. Right?

~Neels