[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r919460 - filtering svn patch targets

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 12 Mar 2010 10:45:20 +0100

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.
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.
(I didn't really think about this before working on fixing #3434
unfortunately.)

> I guess 'svn patch' should enable Tortoise to be ignorant about what a patch
> file format looks like.

That's what the diff parsing API does. We just need to make it public API.

> So anything it does with patches should be done by
> svn. In effect, whatever Tortoise wants to do with a patch has to be
> implemented in svn, taking away dev time from wc-ng, pristine store and <add
> cool features>.

So svn patch is not a <cool feature>?

I want to see the basics of the 'svn patch' feature through to completion
for 1.7. We have enough features that were released in a half-baked state.

> The real question is: how much effort shall we invest at this point into
> selectively applying patches? Can it wait for a later release? Can someone
> who really needs it implement it?

Nobody can implement anything before discussing what needs to be
implemented (which is what this thread is about).

Stefan
Received on 2010-03-12 10:46:14 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.