[Monotone-devel] Attempted discussion reboot: line-endings

[Nathaniel Smith]

There is a page on the wiki from last time this line-endings came up,
that summarizes some of the previous discussion (which the current
discussion, umm, seems not to have even fully caught up with):
  http://venge.net/monotone/wiki/LineEndingMunging

I see basically two, quite different, things that people want wrt
line-endings:
  a) validation before checkin
  b) automatic conversion at checkout/checkin time

(a) is really not specific to line-endings; people want to enforce all
kinds of style guidelines.  ("No tabs", "no lines longer than 78
characters", "quasi-sane indentation", ...)  This is a bit of a sticky
issue in a DVCS, because you cannot straightforwardly enforce any such
rules in the same way you can when there is a central server
validating all checkins.  Also, the monotone philosophy is that
validation is _generally_ speaking something that you want to do
_after_ checkin (but before merge), rather than before.  Some people
have made the argument that very simple checks like scanning for tabs
are most conveniently handled before checkin, and I can see the point.
In any case, if there are people who want to add pre-commit checking
to monotone, they should start a different thread to talk about it.
Line-endings are mostly a distraction to this.

(b) is something that people have come to expect from VCSes (given the
at least CVS, SVN, p4, clearcase support it...), and while it's kind
of annoying to support I can see the point here too.  The discussion
from before (as summarized on the wiki page) seems to come down to:
  -- the only important cases are "no conversion" and "\n in repo,
     native EOL in workspace"
  -- enabling the latter behavior should be controlled by an attr
  -- there should be a convenient way to automatically set this attr
  -- we should never to any lossy conversion (e.g., convert a file
     containing mixed \r\n and \n to all-\n).  This guarantees that
     even if a binary file accidentally has the attr set, it cannot be
     irrecoverably destroyed.
  -- however, this means that we need to have some sensible strategy
     for what we _should_ do when we encounter a file with mixed or
     wrong line-endings.
Assuming these summary points are correct, I think this gives the
following action items, if anyone wants to improve monotone's
line-ending support in this respect:
  -- implement a nice mechanism for automatically setting attrs on
     files (.mtn-autoattrs?)
  -- pick some least-bad strategy for how to respond to files with
     mixed line endings
  -- use this strategy to implement line-ending conversion

Personally, I'm also open to the argument that line-ending conversion
is obsolete, and (a) alone is all that's really needed.  (E.g., I
could imagine that if the only tools that cared about line endings
were compilers, then it might be more appropriate to add line-ending
conversion support to your buildsystem than to your VCS; but that's
just one possible situation.)  But this all depends on user needs and
situations and what people want to invest the time into implementing.

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould