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

Re: Failure using "svn patch" with Git patch that adds files. Wrong path is used.

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 5 Nov 2011 16:37:03 +0100

On Sat, Nov 05, 2011 at 06:29:16PM +0400, Konstantin Kolinko wrote:
> 2011/11/5 Konstantin Kolinko <knst.kolinko_at_gmail.com>:
> > Hi!
> >
> > My colleague uses Git to work on one of Apache projects. He published
> > a patch, but I have problems trying to apply it cleanly with "svn
> > patch".

There are several described in your report.

I find your report a bit confusing. Can you please take the time to clearly
break down the different failure modes and the expected/actual behaviour
for each case? Moving away from your big git patch example to simple small
patches that show _individual_ problems, not conflations of several

I think your report boils down to the following points, but maybe I have
missed something:

 - Yes, reverting added files leaved behind unversioned files, and they
   get in the way when you apply a patch, revert, and apply again.
   This is not a problem in 'svn patch', but in how 'svn revert' is
   handling added files. The current behaviour of 'svn revert' is
   intentional and it makes sense. Maybe an option or script to clean up
   unversioned files would help.

 - 'svn patch' uses the same filename detection algorithm that standard
    unix patch uses (the Larry Wall implementation -- I believe GNU patch
    deviates a bit):

          [...] 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).

    Currently, "/dev/null" is not special-cased (it is most certainly
    special-cased in git), which causes one of the problem where a file
    is added with a wrong name.
    I think this should be fixed in 'svn patch', so that '/dev/null'
    is treated in a special way.
    Until then, edit the patch and replace "/dev/null" with a better path.
 - The strip count passed to 'svn patch' is global for the entire patch.
   So if you have "/dev/null" and "b/foo/bar", it strips both, according
   to these rules:

  --strip ARG : number of leading path components to strip from
                             paths parsed from the patch file. --strip 0
                             is the default and leaves paths unmodified.
                             --strip 1 would change the path
                             'doc/fudge/crunchy.html' to 'fudge/crunchy.html'.
                             --strip 2 would leave just 'crunchy.html'
                             The expected component separator is '/' on all
                             platforms. A leading '/' counts as one component.

   As far as I understood your report you are simply seeing the above,
   intended, behaviour. I toyed with the idea of having multiple strip
   counts, but the user interface was getting way too complex to be useful.
   Just edit the patch to make the number of path components match up.

   This seems to be only a problem for you with "/dev/null" though,
   so fixing that case would probably also fix this point for you.

Does all that make sense?
Received on 2011-11-05 16:37:45 CET

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

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