Rejected patch hunk resolving
Hans-Emil Skogh
This is sort of a long shot, but I thought I'd drop a post on the list anyway.
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? That is; showing the rejected hunks inline with the rest of the source as conflicted rows and letting the user select what lines that should end up in the "patched" file.
The three files would then be:
- Original
The file before patching
- Patched
The file after svn patch
- Conflicts
The "Patched" file, but with the rejected hunks forcefully* applied
The lines that differ between "Patched" and "Conflicts" would then be used to denote which lines that are conflicted.
*Forcefully here means doing a best guess of where the hunk should be applied. If no part of the hunk matches, I guess that line numbers would be a best guess of where to put it.
I'm not sure if this would be feasible to do in TortoiseMerge today, but it sure would come in handy when applying large patch files on "dirty" working copies.
Hans-Emil
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2862339
To unsubscribe from this discussion, e-mail: [dev-uns...@tortoisesvn.tigris.org].
Stefan Küng
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.
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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2863543
Hans-Emil Skogh
>> 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