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

Re: svn commit: r996581 - in /subversion/trunk/subversion: libsvn_diff/parse-diff.c tests/cmdline/patch_tests.py

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 16 Sep 2010 14:27:00 +0100

Stefan Sperling wrote:
> Looking at the patch(1) man page, it sounds like we don't really need
> to reinvent the wheel here:

Phew! - wheels are complex, and the ones we make too often seem to have
nails sticking out of them.

> patch will choose the file name by performing the following steps, with
> the first match used:
>
> 1. If patch is operating in strict IEEE Std 1003.1-2008 (``POSIX'')
> mode, the first of the ``old'', ``new'' and ``index'' file names
> that exist is used. Otherwise, patch will examine either the
> ``old'' and ``new'' file names or, for a non-context diff, the
> ``index'' file name, and choose the file name with the fewest path
> components, the shortest basename, and the shortest total file name
> length (in that order).
>
> 2. If no file exists, patch checks for the existence of the files in an
> SCCS or RCS directory (using the appropriate prefix or suffix) using
> the criteria specified above. If found, patch will attempt to get
> or check out the file.
>
> 3. If no suitable file was found to patch, the patch file is a context
> or unified diff, and the old file was zero length, the new file name
> is created and used.
>
> 4. If the file name still cannot be determined, patch will prompt the
> user for the file name to use.
>
> I suppose we could implement the method described in step 1.
> That would make us compatible to UNIX patch, and should resolve the two
> use cases I have in mind.
>
> Step 2 doesn't apply to us. Step 3 is used already. Step 4 could be
> implemented as well (but I'd prefer to do that post-1.7).
>
> Thoughts?

+1 to step 1.

- Julian
Received on 2010-09-16 15:27:44 CEST

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.