[darcs-users] Re: Line endings opinion poll (with bonus option)

David Roundy droundy at abridgegame.org
Thu Nov 4 12:19:29 UTC 2004

On Thu, Nov 04, 2004 at 08:06:02AM +0100, Peter Strand wrote:
> Björn Lindström wrote:
> >Martin Schaffner <schaffner at gmx.li> writes:
> >>How about a single --using-dos-line-endings option for all relevant
> >>commands, that is disabled by default, can be added to
> >>_darcs/prefs/defaults, and does:
> >>
> >>* Turn '\n' into '\r\n' when adding lines from patches into working
> >>* Turn '\r\n' into '\n' when creating patches from working
> >
> >...
> >Still, it may be a good idea to make the options take arguments, like:
> This is basically what I implemented a couple of days ago, by modifying
> (read|mmap)FileLinesPS and writeContents to adapt line endings.
> I that enough? I'm not that familiar with the IO-paths in darcs.
> I also had to add an extra argument to a lot of the functions in
> SlurpDirectory.lhs to allow the desired line ending to be specified,
> since that is a repo-preference or command argument, which
> slurpdirectory knows nothing about.
> Not very pretty.

I think I'd rather move towards abstracting away slurpies from the command
code.  I'd rather implement pairs of functions

write_working_directory :: FilePath -> Slurpy -> IO ()
write_current :: Slurpy -> IO ()

In both cases, it would be taken as a given that the working directory is
the repository directory (the FilePath argument would be used for things
like creating a test directory).

These functions would then look up the line endings preference on their
own.  The latter is related to some work that Juliusz has in
darcs-unstable, and wouldn't need to look up the line endings, since it
would always use '\n'.

Also note, that these two functions could, of course, be implemented using
your modified slurpy functions.

The big reason for my feelings on this is that I think that _darcs/current/
should always have '\n' line endings.  If we don't have a "standard" set of
line endings in _darcs/current/, users will be able to corrupt their
repositories just by changing their line endings option, which would be
bad.  The down side is that will be a performance penalty associated with
using windows line endings, since the file sizes in _darcs/current won't
match those in the working directory, so (unless we do something tricky)
darcs will always read in all files when doing a diff (e.g. whatsnew or
record).  But the benefit will be that the worst thing a user can do by
changing his line-endings preferences is record a patch modifying the line
endings of all files.  That's annoying, but it sure beats introducing
corruption to the repo, and when users start messing with line endings,
they're always going to be capable of messing up line endings.

> The repository with these patches is available here:
> http://zarquon.se/repos/darcs-line-ending-option
> But it's not very well-tested at the moment. Or tested at all.
> However, I need this functionality now, so it will be tested and fixed
> in a couple of days ;)


I'm also a little concerned about your crlfLinesPS, which isn't really
robust with respect to files with messed up line endings.  In particular,
if there are any instances of '\r' that aren't followed immediately by '\n'
it looks like you could have trouble.  I'd rather parse dos line endings by
looking for the '\n' and ignoring the preceding '\r' if it exists rather
than the other way around, but in any case we had better check.

Another vague idea is that if we defined a "dos line endings" environment
variable, it would be relatively easy to run all the existing tests both
with and without line endings, which might help flush out any bugs.

And don't take my criticisms as discouragement, I'm definitely very glad
you're working on this.  I just want to make sure we do it right.

On a purely aesthetic note, I think I'd rather have the configure and
command-line options not be of the x=y sort, but rather something like
--use-dos-line-endings and --dont-use-dos-line-endings.  In particular, I
sincerely hope (and expect?) never to have to add a third line-ending
option.  And unix line endings are "canonical", in the sense that you can
store a few dos-line-endings files in a unix-line-endings repository but
not the other way around.
David Roundy

More information about the darcs-users mailing list