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
signature.asc
Description: OpenPGP digital signature
