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

Re: svn patch and missing targets

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 8 Jan 2013 14:13:47 +0000 (GMT)

Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 11:03:41AM +0100, Neels Hofmeyr wrote:
>>  I've just used 'svn patch'. There were missing target files, but I only
>>  noticed a lot later; because all the text conflicts had .svnpatch.rej
>>  files, but the missing targets were only listed in 'svn patch' output.
>>
>>  So in my particular case it would have helped to have .svnpatch.rej
>>  files for missing targets. I would have noticed the lack of a target
>>  and I could have immediately looked at the diff chunks without
>>  having to browse through the original patch file. Does that
>>  generally make sense? It would sometimes need to create parent folders
>>  to place a rej file...
>>
>>  ~Neels
>
> Yes, it should probably do that.
> However, simple user errors such as using the wrong --strip argument
> can create a *lot* of skips. So I'd prefer a single
> 'svnpatch.skipped.rej'
> within the target dir, rather than littering the working copy with
> a lot of 'svnpatch.rej' files.
>
> Note that UNIX patch creates a single Oops.rej files for files which
> don't exist.
>
> Assume for a second that 'svn patch' already had the ability to flag
> conflicts in the working copy (this is a planned feature). Should we
> then still create an unversioned skip file or do something else?

My preference: We should create conflicts in the WC, containing sufficient info for the user, including a reference to the original patch file when possible, and *not* write reject file(s) into the WC for skipped targets.  Also I would seriously consider doing the same for all conflicting or otherwise rejected hunks, not writing any .rej files at all (after giving due thought to backward compatibility and so on).

- Julian
Received on 2013-01-08 15:14:24 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.