monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Bug in CRLF conversions


From: Yury Polyanskiy
Subject: Re: [Monotone-devel] Re: Bug in CRLF conversions
Date: Sun, 29 Jan 2006 14:22:14 -0500

On Sun, 2006-01-29 at 19:42 +0100, Jon Bright wrote:
> Me too.  I've always argued that the database should have the canonical 
> form (and that this canonical form should be LF-only for text files and 
> whatever-the-file-has for binary or other "don't mess with the line 
> endings" files).  My reasoning goes:
> 
> 1. Everyone's databases should contain the same contents after the same 
> set of operations, independent of platform.
> 2. The hash of a file in the DB must thefore be the same for everyone.
> 2. This hash must therefore be based on a single canonical form.
> 3. Since LF-only is the most common form for the files monotone is most 
> often dealing with, choose LF-only as the common form.
> 
> --
> Jon


Ah, ok! I see. You mean if Joe created a text-file in Windows and Ann
created the very same text-file (except for damn line endings) in Linux
you want them to be identical in DB even if Joe was dumb enough to not
setup line ending conversion for the file? Is it what you say?

I don't understand then. get_linesep_conv() hook returns TWO lineseps
exactly because it says "database version of linesep is such" and "I
want linesep to be such". (BTW, thank you very-very much whoever did
this: it's a VERY wise thing that linesep_conv() returns two lineseps).

Question to Jon and Richard:
    Current design of get_linesep_conv() interface (with two lineseps)
means I *CAN* define db internal linesep. Do you say that this should be
removed?  If I understand you correctly you want get_linesep_conv() to
return for each file only one of two answers: "binary file, don't mess
with conversion", "text-file, MY copy should have ending XXX". And then
monotone always just converts from internal LF-only to XXX. Is it what
you say?

If so then maybe you're right. However, current design supercedes that
and allows more flexibility (I can't imagine though why would anyone
object to storing text-files in LF-only internally).

Anyway. The original problem was that whatever you want conversion to do
we expect it to be reversible and return unchanged files to original
state. 

Cheers,
-up





reply via email to

[Prev in Thread] Current Thread [Next in Thread]