Am Sat, 03 Jul 2010 19:12:40 +0200 (CEST) schrieb Richard Levitte <rich...@levitte.org>:
> 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). Now, if that attribute is set, Subversion ensures that the file in the workspace has exactly that line ending scheme (and uses some normalized format [namely LF] inside the repo, but that's basically transparent to the user). This however has a side-effect, which may be unexpected at first sight: During a commit, the file *in your workspace* may change, so that after the commit, the line ending scheme matches that specified by the property. If at commit time a file has the 'eol-style' property set, but has inconsistent (i.e. mixed) line-endings, the commit is rejected. 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. Regards, Thomas _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel