monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Spaces in filenames, UTF-8, and newlines (was: mono


From: graydon hoare
Subject: Re: [Monotone-devel] Spaces in filenames, UTF-8, and newlines (was: monotone & CVS import)
Date: 12 Nov 2003 17:08:26 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Kevin Smith <address@hidden> writes:

> I'm glad you're addressing this, because monotone absolutely must
> allow spaces in file paths, or I won't be able to use it. Some RCS
> projects are willing to disallow spaces, unfortunately.

ok. that's 2 strong votes for 0x20. I guess it'll have to be supported :)

> I would probably consider the first component to be everything up to
> the first space, and the filename everything after that (rather than
> relying on exactly 40 characters). I think \n is the right
> terminator to use. I really like non-binary data files.

yeah. I'm leaning towards this too. I'll have to cook up some tests to
see which parts of ASCII and/or UTF-8 are interpreted various ways on
various unices, plus I guess mac and windows machines. if I can find a
mac anywhere... until then, I can at least do 0x20 in short order.

> Makes sense. I think we should allow UTF-8 filenames, as you mentioned
> in that earlier thread.

hope hope. like I say, it'll depend a lot on the results of
portability testing, which I haven't done a great deal of yet. I'm not
going to add general UTF-8 path support if there's a way to punch out
of the working copy on any major OS using funny UTF-8 bytes. at least
not in the main build. maybe with

  ./configure --enable-shoot-myself-in-the-foot-mode

or something :)

> Have you already "solved" the cross-platform newline issue? As a
> maintainer of a cross-platform app, this is also an important feature
> for me. I don't really know the right answer, but somehow between the
> tools and some conventions, cross-platform work has to be possible
> (without too much pain).

eh.. not just yet. problem is, the only thing I can think of which is
acceptable from a user's perspective is transparently washing and
unwashing newlines when reading and writing files. but that is so
uninspiringly against the general design (binary-clean, SHA1(file) ==
version) that I can't imagine turning it on by default.

maybe permit a (default undefined) hook, and if you put:

 function wash_line_endings (name)
        if (string.find(name, "%.c$")) then return true end
        return false
 end

in your .monotonerc, you give up being able to run sha1sum on your .c
files anymore, and I have a strong statement in the manual about how
this makes sha1sum useless on your files. would that do?

-graydon





reply via email to

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