RFC: loosening file name limits

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jelmer Vernooij wrote:
| On Thu, Jul 31, 2008 at 08:09:22AM +1000, Robert Collins wrote:
|> So we have a number of limits on file names.
|
|> must be unicode
|> must not contain \\ and various other unportable characters
|> must serialise cleanly within our various storage formats
|
|> I think the first constraint is very useful for portability; the
|> following is not about that.
|
|> The second constraint can be regarded as bzr being a guardian - which
|> just gets in the way sometimes.
|
|> We don't guard against many other user-code portability issues like
|> having "README" and "Readme" in a single dir; I think we should get rid
|> of the second constraint in favour of a nag/warn system where unportable
|> tree layouts are [optionally] warned about but not prohibited.
| Yeah, I think this the right way to go.
|
| Even if we decide to keep disallowing the addition of filenames that
| contain the second category characters, it would be nice to allow such
| filenames to exist in history for the sake of imports from foreign
branches
| that do allow them.
|
| Cheers,
|
| Jelmer
|
|

So, number #3 is the harder one, as allowing '\n' and '\t', etc into
path names is going to break all of our current serializers. (Even
dirstate uses '\n' as a delimiter).

The reason for '\\' isn't so much about portability, it is because
internally on win32 we do "path.replace('\\', '/')" in lots of places.
So if you commit a file with '\\' and check it out on win32, you get to
keep the pieces, and it will take a fairly large amount of code auditing
to make sure we clean up all of that. (I can guess where the api
abstractions *should* be, we've just chosen to force it throughout the
whole api to make it easier on ourselves.)

Which means that ATM, it is probably really hard to know on win32 if
there is a '\' in the path, or if it is just another directory
separator. (I guess if we check just '\\' in IE.name...)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiQ7JYACgkQJdeBCYSNAAOPgwCgh6CQHYWhI0mpFsIKrUae0I77
9vcAoL6T/e4U6IPANnsooxl6bKm6p8Ba
=uHSf
-----END PGP SIGNATURE-----