On Tue, 6 Dec 2005 kfogel@collab.net wrote:
> lundblad@tigris.org writes:
> > --- trunk/subversion/libsvn_diff/diff_file.c (original)
> > +++ trunk/subversion/libsvn_diff/diff_file.c Tue Dec 6 03:11:59 2005
> > @@ -1197,13 +1188,31 @@
> >
> > [...]
> >
> Fascinating.
>
Oh, yeah, real magic going on:-)
> I realize it's heuristic anyway, but: if we find a CR in the very last
> byte we're allowed to look at, then it's "equally" likely that the
> next byte is LF as not... In other words, is there a compelling reason
> to prefer "\r" over "\r\n" in the unknown case? Wouldn't it be more
> consistent to return NULL? In other words:
>
This function is used when the whole file (!) is in memory. Since I'm not
saying that this works for a chunk of a file, I'd say this is to be
assumed.
Yes, the merge output code actually fetches the whole files into memroy at
once. Don't ask me why, but that's how it is. Have you heard anywone
having problems with it. This is fascinating:-) But maybe mergable files
that are such big that they won't fit in memory arre really rare...
Thanks for reviewing,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 6 23:45:20 2005