[Top][All Lists]

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

Re: [Monotone-devel] OS-specific line endings

From: Stephen Leake
Subject: Re: [Monotone-devel] OS-specific line endings
Date: Sun, 04 Jul 2010 05:53:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Thomas Moschny <address@hidden> writes:

> Am Sat, 03 Jul 2010 19:12:40 +0200 (CEST)
> schrieb Richard Levitte <address@hidden>:
>> The usual problem is there, how to make certain we don't do
>> conversions with files that should be seen as binary but aren't
>> obviously so from a technical point of view.
> That's the easy part: don't do anything per default, and do line ending
> conversions only if the file has some 'eol-style' attribute set.


> The not-so-easy part is to get all corner cases right. SVN needed
> several versions for that, iirc, but now has a working solution, which
> might be worth to look at.
> It works like this: A file can have the 'eol-style' attribute
> ('property' in SVN speak) set to one of 'native', 'CRLF', 'LF' or
> 'CR' (where 'native' means the line ending style of the OS the
> Subversion client is currently run on).
> ...

That makes sense if we are trying to solve "the general line ending
problem". I'm not actually proposing to do that, because I don't think
it is necessary.

I'm trying to find an efficient way to allow the user to provide a
transformation that should be applied whenever a file is extracted from
the database and placed on disk, and the inverse transform.

If the user wants to use that for line-endings, that's fine. I imagine
there are other similar uses.

The core problem I see at the moment is to get 'mtn status' and 'mtn
inventory' to not report the transformed files as changed.

> Again, Subversion needed some time to get it right, and we should avoid
> hitting the same issues they did. Any ad-hoc solution might give us
> headaches later.

I hope the mechanism I end up implementing could be used in a general
line ending solution, if we ever decide we need one. I don't think we

-- Stephe

reply via email to

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