On 12.03.2010 10:45, Stefan Sperling wrote:
> On Fri, Mar 12, 2010 at 03:11:06AM +0100, Neels J Hofmeyr wrote:
>> Stefan Sperling wrote:
>>>>> What is not possible (without adding the --include-pattern option)
>>>>> is selecting which files to patch. Is selecting individual patch
>>>>> targets really that important?
>>>> Yes, that's very important. I often find that when I get a patch, I
>>>> only want to use part of it because I found that when reviewing the
>>>> changes I have to reject some of those changes.
>>>
>>> I'm not sure if this use case is worth optimising for.
>>> You could easily apply the patch, and then selectively revert
>>> some of the patched files. What you are describing is a special
>>> case of "I want to apply this patch and also make custom modifications
>>> to the patched result." Why not just apply the patch and then make
>>> the necessary modifications? Or request a revised patch from the patch
>>> submitter?
>>
>> I do see what Stefan K is getting at. Stsp, your revert workaround does not
>> work when there already are modifications on the files prior to patching.
>
> It does. You can manually revert the edits 'svn patch' made to the file.
But that requires that the user knows for *sure* which changes are made
by the patch file and which ones were already there. And believe me,
many users won't know that, especially if they made a lot of changes to
that file.
> Whether this is feasible or not really depends on the kind of modifications
> the user and the patch are making. But it seems to me like the tortoise
> GUI was designed around the assumption that users will often want to
> apply only parts of patches at file-level granularity. I don't believe
> that this is what people do in reality, so I'm questioning this GUI
> design because it has repercussions on the svn patch API.
Well, *I* usually do that, and so do many others I know.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2010-03-12 20:13:18 CET