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: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Re: Bug in CRLF conversions
Date: Sun, 29 Jan 2006 20:42:44 +0100 (CET)

In message <address@hidden> on Sun, 29 Jan 2006 14:22:14 -0500, Yury Polyanskiy 
<address@hidden> said:

ypolyans> Ah, ok! I see. You mean if Joe created a text-file in
ypolyans> Windows and Ann created the very same text-file (except for
ypolyans> damn line endings) in Linux you want them to be identical in
ypolyans> DB even if Joe was dumb enough to not setup line ending
ypolyans> conversion for the file? Is it what you say?
ypolyans> 
ypolyans> I don't understand then. get_linesep_conv() hook returns TWO
ypolyans> lineseps exactly because it says "database version of
ypolyans> linesep is such" and "I want linesep to be such". (BTW,
ypolyans> thank you very-very much whoever did this: it's a VERY wise
ypolyans> thing that linesep_conv() returns two lineseps).

Consider if Joe has get_linesep_conv() return {"CR","LF"} and Ann has
get_linesep_conv return {"LF","CR"}.  That means that Joe would have
CR for the internal representation of linesep (in the database) while
Ann would have LF.  Then they synchronise their databases.  Oops.

ypolyans> Question to Jon and Richard:
ypolyans>     Current design of get_linesep_conv() interface (with two
ypolyans> lineseps) means I *CAN* define db internal linesep. Do you
ypolyans> say that this should be removed?

Yes.

ypolyans> If I understand you correctly you want get_linesep_conv() to
ypolyans> return for each file only one of two answers: "binary file,
ypolyans> don't mess with conversion", "text-file, MY copy should have
ypolyans> ending XXX". And then monotone always just converts from
ypolyans> internal LF-only to XXX. Is it what you say?

Exactly.

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

Doesn't matter if anyone would object or not.  The possibility is
there, and sooner or later, someone *will* use it.  Hasn't Murphy
taught you that if it's possible to screw something up, someone will
eventually do it?

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

A long time ago, I've argued that no conversion should be made, that
files should be stored internally exactly as they are outside.  It
*would* solve that particular problem, but unfortunately, it makes
external representation on all "incompatible" systems.  And trust me,
when monotone gets ported to VMS, such a move would be deeply
regretted.

There is no perfect way to solve this, and the best so far is to mark
all non-text files as "don't touch this", and have the internals of
monotone obey that no matter what.  Right now, we're only half way
there, with the "manual_merge" attribute, which is only considered
during, you guessed it, a merge.

The only reason that we haven't had much problems yet is that most of
us run on Unix, with get_linesep_conv undefined, which means no
conversion is made.  I wonder how people on Windows handle this.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

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