monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: .mt-attrs formatting


From: Bruce Stephens
Subject: [Monotone-devel] Re: .mt-attrs formatting
Date: Thu, 19 Aug 2004 23:00:10 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

"graydon hoare" <address@hidden> writes:

[...]

> no doubt. but neither will pretending like we can "intelligently"
> guess when a user means to have leading or trailing spaces and when
> they do not. apparantly some users do. windows users seem to like
> this stuff.

I don't really mix with Windows users that much (only with Unix
developers who have to use Windows sometimes), but I suspect filenames
which begin or end with whitespace really aren't that common.  Not
that it matters, since I agree it would be good to support it.

>> Or have a completely different delimiter than space.  I've no idea
>> what syntax you're imagining that basic_io.cc would handle...
>
> it uses delimiters and a numeric byte count. [sNN:<NN bytes>].
> that's why. it has 2 things going for it:
>
>  - by having a number (thus requiring arithmetic) it says "hands off"
>  - by having delimiters *and* a number there's a good chance we'll
>    notice when the user sticks their fingers in it anyways.

That's good for something that's managed by programs, but .mt-attrs
isn't, at present.  Do you envisage it changing to being a file that's
not normally edited by users?  For controlling whether files are
executable that seems sensible, and similarly for symbolic links and
things, I guess.  But what about other uses?

Anyway, it sounds like the code fix you want is non-trivial, so I
suggest something like the documentation change I gave earlier (at
least so the example has the correct format).  It's a surprising
format, but if the documentation makes it clear then people can live
with it until the changeset branch is ready.  I was thrown by it
simply because the documentation wasn't explicit, and the example was
misleading.




reply via email to

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