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

Re: svn commit: r17645 - in trunk/subversion: libsvn_diff

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-12-06 23:36:55 CET

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

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,

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

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.