On 9/8/07, Mark Phippard <markphip@gmail.com> wrote:
> OK, I do not think that was clear before. I did not think your option
> #1 was ever a real goal for this feature. It would obviously be a
> cool addition, but not a must-have at all.
Mark, could you please have a look at
http://svn.collab.net/repos/svn/branches/svnpatch-diff/notes/svnpatch
and see whether "V PATCHING" part is clear on this matter? If not,
I'll try to improve so that other users don't get it wrong.
> A couple of questions:
>
> 1) Can patches be applied to working copies that do not have the exact
> same revisions of the files that were used to produce the patches? I
> recall this being discussed on the list in the past.
Yes, since svnpatch is revision-less and checksum-less (except for
binary files). And if your browser is still opened on notes/svnpatch,
you'll find of interest part VI :-)
> 2) Are there any public API's in your code to interrogate the patch
> contents? I am trying to think of how a visual patch apply tool like
> TortoiseMerge could be extended to show what is in the patch and allow
> the user to selectively apply portions of it.
Yeah, sounds like a great idea! Here's svn_client_patch() signature:
svn_error_t *
svn_client_patch(const char *patch_path,
const char *wc_path,
svn_boolean_t force,
svn_boolean_t dry_run,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
@a patch_path is supposed to be the full encoded patch. The tool
could pass a subset of a patch -- the selected encoded portion -- and
svn_client_path() would do job. However (!), an editor drive is going
to happen (svn_client_patch() calls svn_wc_apply_patch() to achieve
this), which means we're waiting for open-root/close-edit commands.
So this can't just be a subset, but a subset with enclosing commands.
Besides this little constraint, I think it works: decode, display
contents to user, user selects, add enclosing commands, encode, invoke
svn_client_patch() with this encoded patch subset. I was thinking
aloud.
Note that in theory, 'svn patch' is _very_ similar to 'svn merge', so
there's no reason this can't work.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 8 18:39:22 2007