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
problems?
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