RE: Re: Merge failure recovery

On 8/04/2015 06:33, Stefan Küng wrote:
> On 07.04.2015 08:55, Gavin Lambert wrote:
> > Sometimes, due to unresolved conflicts (eg. when the user has
> > selected "resolve later"), SVN aborts during a merge and requests
> > that the user perform the merge again. Which is fair enough.
>
> This happens when there's a conflict on a path, and then one of the next
> revisions to merge need to apply a change to that (now conflicted) path.

I don't think that's the case. When I tried it the first revision I was merging had a mixture of tree conflicts (which I used "resolve later") and content conflicts (which I resolved during the merge). The merge aborted after the first revision. I then fixed up the remaining conflicts and re-ran the merge on the remaining revisions and they merged cleanly (one or two content conflicts resolved inline, but otherwise no issues).

So I don't think it needs a further modification on a conflicted file to abort, it just needs any unresolved conflicts.

> But: in most situations, the merge failed because either the revision
> range or the merge url was wrong in the first place. That's why I never
> implemented a 'remember' feature.

I've just explained a situation where that's not the case. I would think that this is more common than merging the wrong thing?

> If a merge fails for me, I usually revert the whole working copy before
> trying the merge again.

That would just generate the same tree conflicts again, and would produce the same result if I said "resolve later" again. Unless you're just saying that I should be resolving the tree conflicts inline instead of using the "resolve later" button -- in which case, why does that option exist?

> > Perhaps the intended solution is simply to never click "Resolve
> > later", instead to resolve everything as it comes up during the
> > merge. But I was wondering if it would be more useful to bring up
> > the Merge dialog again with the same settings on failure, similar to
> > how a failure to commit will update and then return to the commit
> > window with the same selections.
>
> not quite as easy as it may seem. There's no guarantee that when the
> merge dialog is opened again that it's opened on the same path or for
> the same merge.

I was suggesting that TSVN re-open the merge window itself at the end of a failed merge (in a similar fashion to an out-of-date commit). That way you can guarantee that it is on the same path. The user can always cancel it if they intend to do something different (or you can ask them, like you do for update-and-commit-again).

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3111370

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-04-08 01:18:37 CEST