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

Re: #3610, How make 'svn patch' able to use the targets lines for intermediate context?

From: Alan Barrett <apb_at_cequrux.com>
Date: Wed, 14 Apr 2010 20:18:06 +0200

On Wed, 14 Apr 2010, Stefan Sperling wrote:
> Yes. Just use whatever comes from the patch, including context lines.
> This is consistent with the current behaviour. I think we should avoid
> special cases where this rule is currently not true anymore.
> (I'm not sure how UNIX patch behaves wrt context lines, actually.
> Might be worth checking.)

If applying a patch ever causes changes to lines that are marked in the
patch as context lines (not as lines to be removed or added), then I
expect people to be unhappy. The context lines in the patch file are
known or suspected to be damaged (or else the user would not have asked
to ignore whitespace changes), so copying the context lines from the
patch is not wanted.

The GNU patch implementation that I just tried does the right thing
here: when passed the "--ignore-whitespace" option, it ignores
whitespace changes in context lines and lines marked as being removed,
and it copies context lines from the input file, not from the patch.

I don't buy the argument that it's necessary, for consistency with
current svn behaviour, to copy context lines from the patch to
the output file. Current behaviour does not include any kind of
"ignore whitespace" option, so the context lines in the input file
are guaranteed not to differ from the context lines in the patch,
so an outside observer (without knowledge of the internals of the
implementation) cannot tell whether the current implementation copies
context lines from the patch or from the input file. Changing the
implementation to copy context lines from the input file would therefore
not be an incompatible change.

--apb (Alan Barrett)
Received on 2010-04-14 20:18:48 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.