request for svnpatch

[Stefan Küng <to...@gmail.com>]

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:

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.

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. 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.


Does this make sense?

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

Re: request for svnpatch

[Stefan Küng <to...@gmail.com>]

Charles Acknin wrote:
> On Fri, Aug 15, 2008 at 7:06 PM, Stefan Küng <to...@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

Re: request for svnpatch

[Charles Acknin <ch...@gmail.com>]

On Fri, Aug 15, 2008 at 7:06 PM, Stefan Küng <to...@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.)

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.

> 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.

> 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 :-)

Charles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org