[Monotone-devel] Re: line endings with 0.31

[William Uther]

Hi,
  I'm newish here, so my opinion might not count for much, but I  
think this is one area where subversion got things right.  I highly  
recommend that people read about subversion's system before making up  
their minds.  http://svnbook.red-bean.com/nightly/en/ 
svn.advanced.props.html  In particular, svn:mime-type svn:eol-style  
and svn:keywords are worth knowing about.

  - Having the mime-type stored can be useful.  You could have a  
hook for inferring this.  By default, subversion leaves it unset.   
This property is used to decide what merge algorithm to use.  i.e. it  
is the mechanism svn uses to mark binary files that shouldn't be  
merged.  An unset entry is considered text, and so will use the  
standard textual merge algorithm.  Anything with text/*  in it is  
also considered text.  There was talk of having plugable merge  
algorithms (e.g. tree merge algorithms for XML files), but I don't  
know if that ever happened.

  - Subversion has a second property for eol conversion.  It can  
have one of five values: "CR", "LF", "CRLF", "native" or unset.

 Unset is the default case, and means no eol conversion.  By  
default, your data doesn't get munged.

 "CR", "LF" and "CRLF" are pointers to svn to normalise the line  
endings before checking in.  These settings are there so that stupid  
editors don't cause people to have spurious diffs.

 "native" tells subversion to convert to whatever the standard line  
endings are for the local platform.  Before checkin the file is  
converted back to "LF" and so that is the eol format in the  
repository.  On checkout the "LF"s are converted to the local standard.

There is a third property it is worth bringing up in this context.   
That is subversion's 'keywords' property.  The keyword expansion  
happens at the same time as "native" line-ending conversion.  This  
property contains a list of keywords to be expanded in the text.  By  
default it is empty and no expansion occurs.  There is a list of  
keywords, "Date", "Revision", "Author", "HeadURL" which would be  
something like "Branch" in mtn, and "Id" which is a short string  
combining parts of the others.  On checkout, when the 'native' line  
ending conversion happens, any keywords between $s are expanded.   
e.g. $Id: $ might become $Id: calc.c 148 2002-07-28 21:30:43Z sally  
$.  On checkin, when the line ending conversion happens, any keywords  
are contracted back to the simple form: $Id: $.  By storing canonical  
forms in the repos, there is no special merge algorithm required.

This system works.  By default it doesn't touch your data.  It allows  
people on different platforms to work together, each with their local  
line endings.  It allows line endings to be forced to one value if  
you want them there and someone keeps corrupting them.  It has a  
canonical form in the repository so that the merge algorithm is kept  
simple.  It doesn't confuse the concepts of 'should I convert line  
endings' and 'should I use line-based merge'.

The one place where you might get a large diff is if you change line- 
ending settings.  e.g. you have a file committed with "CRLF" line  
endings and no line ending property.  In that case, svn will not be  
doing any conversion for you.  If you then set the line ending  
property to "native", you will get a one-time diff that includes the  
property change, and the file-diff that changes all the line-endings  
to "LF"s.  If this is done at import time or soon afterwards it isn't  
a problem.  Done later, it is more of a problem :( - you'd need fancy  
merge algorithms to merge past the line-ending change.

Of course, this is only a problem if the repos wasn't already in the  
right format.  Adding a "native" setting to a document made on Unix  
with "LF"s is not a problem at all, neither is adding a "CRLF"  
setting to document already using "CRLF"s.

Be well,

Will            :-}