Charles Acknin wrote:
> On Fri, Aug 15, 2008 at 7:06 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> Hi,
>>
>> I've checked out the svnpatch-diff branch some time ago to find out what
>> new API's are available. I've mentioned this before, I'd like to have
>> additional API's available:
>
> Thanks for having a look! I've mostly been offline wrt Subversion for
> the last couple months (writing my MS dissertation). I'll have more
> time in September to further look at your request if nobody showed up
> meanwhile.
>
>> currently, the only API available is svn_client_patch().
>> I would need APIs to:
>> * list all affected files/folders in a patchfile:
>> - affected file path
>> - maybe size of the patch part for that file
>> - whether content or properties are affected
>> - new name/path in case of a rename
>> * ability to apply part of the patchfile, affecting only one of the
>> possible paths
>>
>> without these APIs, it won't be possible to get a preview before
>> actually applying the patch.
>
> I had started implementing the dry-run mode for 'svn patch', but it
> was disabled at some point to let further development take place on
> the branch instead, I can't remember why/what exactly. Would dry-run
> help here? (Note that I'm not saying there's no need for more APIs to
> svnpatch; there is definitely.)
It depends on the output of the dry-run. If I can get the information I
need from that dry-run, then sure it would help.
>
> I'm curious, how do you deal with doing the same thing for 'svn merge'
> in tsvn for instance? Say you want to obtain the list of paths
> affected by a merge operation.
That's a different UI. For the merge dry-run, I just show the same info
dialog as for the real merge. Those are the info callback messages and
are only for the user. I don't use those messages in TSVN directly to do
something with them.
It's different for the svnpatch however: I need the information so I can
show the user a dialog listing all the affected files. Then the user can
doubleclick on every one of those files to get a preview. And then the
user can save that preview, which applies that part of the patch.
That's very useful because a lot of patches I get have completely
unrelated changes in it which the user forgot to remove from the
generated patchfile. I don't want to apply the changes to those files,
so I can simply choose which files I want to have the patch change and
which ones not.
>> the svn client could also use these:
>>
>> svn list --svnpatch patchfile
>> file1 : modified
>> file3 : renamed to file3_new
>> file2 : moved to file4
>> file4 : added
>>
>> or something like that.
>
> I don't think the 'list' subcommand is appropriate here according to
> its semantics (help list says "list (ls): List directory entries in
> the repository."). The output of 'svn patch --dry-run' would be very
> similar to the one you mentioned.
Sure, that was just a (stupid, I admit) example. Of course it would have
to be a subcommand of 'patch'.
>> And then if the user doesn't want to apply the
>> full patchfile but only parts of it:
>>
>> svn apply --svnpatch patchfile file1
>> would only apply the modifications for file1.
>
> Good idea! Just copied that to my TODO list. Oh, and it's 'svn patch' btw :-)
Again, sorry for the stupid example. I promise I will do better next time :)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-08-25 18:07:05 CEST