> From: Philip Martin [mailto:pm@localhost]On Behalf Of Philip Martin
> Sent: 25 April 2002 13:31
> Zack Weinberg <zack@codesourcery.com> writes:
>
> > On Thu, Apr 25, 2002 at 03:20:56AM +0200, Sander Striker wrote:
> > > I always wondered why we needed that \No newline at end of file crap.
> > > If there is no newline on the end of file, don't output a newline.
> > > What's wrong with that?
> >
> > That would be far too easily lost or confused. For instance, if the
> > diff is embedded in an e-mail message (which happens all the time) or
> > if there's a diff of another file after that one (ditto), a newline
> > will get added, or the boundary between diff and what-comes-after will
> > be mangled.
>
> It's worse than that, it simply doesn't work. For instance the patch
>
> @@ -2,4 +2,4 @@
> B
> C
> D+1
> -E+1
> \ No newline at end of file
> +E-1
>
> would become
>
> @@ -2,4 +2,4 @@
> B
> C
> D+1
> -E+1+E-1
Ah, I see.
> which a) will confuse existing tools, and b) even a custom tool could
> not decide where to split the last patch line.
>
> We need the '\ No newline' stuff.
Ok. The only thing I have to say is that it should go in the output
implementation. Signalling for this doesn't belong in the svn_diff_output
function. The rationale behind that is that it doesn't know anything
about lines. It only cares about tokens (token ranges actually). What
we do with the token ranges is up to the implementation of the output
(in this case output_diff_modified) function.
With unified diff output you want to display 3 lines before and 3 lines
after the actual differences; when you encounter EOF while you still want
to write lines and there is no \n at the end of the file, you output the
'\ No newline at end of file' thingy.
I personally think the merging of two diffs into one hunk* is going to cause
us more headaches.
Sander
*) When two diffs are near their context may overlap, requiring them to
be in one hunk.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 25 14:04:10 2002