Re: Rejected patch hunk resolving

>> I have been doing some patch applying as of late, and some of them on
>> modified working copies. This invariably leads to that some patches
>> generates rejected patch hunks. This is expected since some of the
>> modifications in the working copy conflicts with the data provided in
>> the patchfile.
>> The question is: Would it make sense to let TortoiseMerge give a
>> little bit more help when it comes to resolving conflicts in
>> patchfiles? Right now the rejected hunks are shown in a new window.
>> Would it be possible to use the three way "conflict" view instead?
...
> The problem is that the rejected hunks could not be applied, and for a
> reason: the patch algorithm couldn't find a place where they could be
> put. TMerge can't apply them and show a conflict, because they can't
> be applied at all.

But the patch algorithm here is being conservative. It expects to find a matching "clean" place to apply the hunk. If we would give the result to a human operator for manual resolving, we could be much more aggressive. That is: Make a best guess where to apply the patch.

Maybe I'm just repeatedly hitting an edge case here, but almost invariably when I was applying the patches here the context lines of the hunks were still present in the code, maybe not on the expected row number, but pretty close. In that case we could simply replace whatever that is present between the context start and end lines in the source with what would have been the result of the patch file. In the process, more or less blindly, throwing away a bunch of lines; which would be OK since the user will be presented with this "conflict" in a nice (and familiar) manner.

> Since we don't have the original file we also can't just apply them
> at their original position the patchfile indicates, so that's not
> possible either.

That was another, much simpler, suggestion that I was about to make, but refrained from since it doesn't (really*) work with "dirty" WC:s.
I'm regularly following the following pattern when applying patches:
1.) Open the patchfile in a text editor and check what revision that the patch was created on.
2.) Use "Update to revision..." to move the working copy back to that revision.
3.) Apply patch.
4.) Update
5.) Resolve conflicts

I guess it would make sense to automate this. It could be an option (or part of a new, more user friendly patch dialog (as suggested (much) earlier), ) when applying a patch to do the above mentioned steps automatically.

* Ok, it works on WC:s with changes as well, but sometimes the changes on the WC will have a hard time surviving going back in time. (The changes may have been on lines that did not exist when the patch was created.) To solve this using the above mentioned method one would have to create a patch with the changes in the WC, then do the time-traveling-patch applying, then apply the patch that was created before. Of course this patch will fail to apply cleanly leaving the user (me :-) ) in a kind of catch 22. Ah well, the final solution (today) is not all that bad; looking at the failed hunks and doing the edits all manually. But there seems to be room for improvements here...

Hmm... The more I think about it, the more I think that an overall overhaul of the apply patch command GUI would probably be more worthwhile as a first step. Perhaps including the automation of the time-traveling-patch-application.

Hans-Emil

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

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-10-26 09:16:31 CEST