monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: line endings with 0.31


From: Rob Schoening
Subject: Re: [Monotone-devel] Re: line endings with 0.31
Date: Tue, 21 Nov 2006 10:06:39 -0800

Here's a thought. 
 
Instead of trying to do EOL conversion, could monotone be made just smart enough to check/warn of file about to be committed with the "wrong" line ending?  That is, have the commit fail if the line endings in the file don't match what the configuration says, possibly requiring a special flag that the user must specify to acknowledge the issue in order to commit the file with the wrong endings.
 
As someone mentioned earlier, using foreign line endings is less of a problem than inconsistencies across files/revisions that creep in purely by accident/oversight on the part of the user. 
 
If you wanted to get a little fancier, if mtn aborted the commit due to what it thought was mismatched endings, it could offer a suggest that the user use a special option to pre-process the file before committing.
 
RS

 
On 11/21/06, address@hidden <address@hidden> wrote:
On Tue, Nov 21, 2006 at 03:58:58PM +0100, Richard Levitte - VMS Whacker wrote:
> In message < address@hidden> on Tue, 21 Nov 2006 09:48:54 -0500, address@hidden said:
>
> hendrik> In monotone, I suggest that a file that has been
> hendrik> character-converted on checkout have its line-end coding
> hendrik> reverted on checkin, on a line-by-line basis.  Thus only when
> hendrik> the user explicitly edits line ends will the end-of-line
> hendrik> coding be changed in the repository.  This would have the
> hendrik> effect that if massive damage is done to a true binary file
> hendrik> if it is mistakenly line-end-converted, the damage would be
> hendrik> mostly undone on subsequent checkin.
>
> What I hear you say is that eol conversion should happen upon file
> extraction.  Then, unless the user explicitely does eol conversion,
> the file is converted back to the original eol format before being
> stored (or the diff being performed).

I had on mind something like this:

eol conversion happens on file checkout.

Upon checkin:

diff ignores the detailed end-of-line coding, except of course to
recognise all end-of-lines as being end-of-lines.  Then after the
regular diff, has been performed,
for each line
do
   if it exists only in the new version,
   then we use the new encoding.
   elsif it exists in both the original and changed versions
     if the user has modified the coding
     then we use the user's coding
     else we use the iriginal coding
     endif
   else if the line exists only in the original
   then no problem, it's gone.
   endif
endfor

>
> I'm sure I misunderstood what you wrote, because my interpretation
> doesn't make sense at all.

By the way, *does* monotone use a line-by-line diff?
I thought it used a character-by-character diff based on compression
technology.

-- hendrik


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel


reply via email to

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