Re: [Arx-users] Re: [Fwd: i18n and file systems]

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > 
> > Thanks.  I had seen this when it came out.  I think that bzr has more
> > problems with filenames because it stores the weave in file names that
> > match the file in the working copy.  ArX stores everything as
> > changesets, so this does not come up as much.  As for dealing with
> > cases where a file can not be created on a particular filesystem, I
> > think ArX will already give a (cryptic) error message.  It most likely
> > will die when unpacking the tarball or when creating a file during
> > patching.
> 
> I was thinking in particular of the discussion we had earlier this month 
> where I proposed encoding branch names such that they could be stored 
> on, and moved to, any filing system. The information in this email 
> reinforces my belief that storing user-chosen text as filenames is a bad 
> idea.

Ah, right.  Escaping filenames makes them longer, so then you can run
into problems with filenames that are too long.  In particular, 7 bit
ASCII is not safe.  I posted an example from comcast that only allowed
letters, numbers, ".", "_" and "-".  Combining that with case
insensitive filesystems really only gives you 5 bits to work with.

However, I think I have come up with a workable solution.  We can use
the 15 character abbreviated hash of the revision name, not the
revision name itself.  Within the branch directory, we have a file
"branch" that contains the real name of the branch.  It is created
when the directory is created and never modified.

Almost all of the commands already know which branch they want, so
they will not even need to look up the branch name.  The only command
that does any discovery is "browse".  This will slow down "browse"
because it now has to copy those "branch" files over.  But browse is
not that common an operation, and a few extra roundtrips should not
kill its performance.  Moreover, for simple repos with only one
default project, it won't make any difference at all.  Unfortunately,
this will suck if you have 10,000 projects (e.g. sourceforge).  They
would want to split up all of projects into different repos anyway,
since you want different gpg keys for each repo.

Cheers,
Walter