Illegal Filesystem characters in revision names

[Jan Hudec]

On Sat, Dec 03, 2005 at 12:39:33 -0600, John A Meinel wrote:
> I'm trying to figure out the best way to handle illegal characters in
> revision names.
> On windows, the forbidden characters in a filename are:
>   \ / : * ? " < > |
> 
> There are also some forbidden strings, specifically you can never name a
> file:
>   prn
>   com1, com2, com3, etc
>   lpt1, lpt2, etc
> 
> I'm guessing there are others, but I haven't been able to find the
> Microsoft Knowledge base article
> 
> The specific thing I'm worried about, is that we are trying to use
> "Arch:" as a prefix for arch imported archives, and this prevents them
> from being checked out on windows.
> 
> I can think of a few solutions:
> 
> 1) Forbid illegal characters in revision names. People could always
> switch to using Arch-some at archive%foo--baz--1.0--patch-2. But using a
> semicolon to define a namespace is really nice.
> 
> 2) URL encode illegal characters. This means that they would always have
> a legal filesystem name. The question becomes, though, when do you turn
> this on. Do you use it on all platforms, or just on windows? When you
> request it, it actually has to be doubly encoded, since http would
> decode it. If we don't use it everywhere, we still have to be able to
> handle it, since some people will publish using an IIS server, and
> others would use Apache.
> An branch format bump could make this cleaner, and just everyone would
> start using the new format.

This will probably be used for the versioned files, but using it for the
metadata does not seem that reasonable. It would have to be used
unconditionally if it was implemented, to make it easier for the
transport.

> 3) Just switch to using a revision.weave file. Since revisions are no
> longer saved directly by their name, we can break ourselves from being
> limited to filesystem constraints. This would also require a branch
> format bump. I'm hesitant to do this until we have knits. We already
> have 1 file (inventory.weave) which scales by the number of commits, I
> wouldn't really want to introduce a second one. (Though it would scale
> better, since the number of lines per revision are much smaller).

Hm, sounds reasonable. I rather thing that since we alrady have one file
that grows for each revision, having another is not as big deal.

> Does anyone have more ideas? I'm leaning towards the third option, since
> we kind of want to do it anyway. And I guess we can just say "arch
> conversions aren't supported on windows until the next branch format".
> Though it might be nice to get it sooner than that, since I've started
> pointing my coworkers to bzr.

Well, does it have to be a weave? What about replacing each of those
directories 00 through ff with respective file 00.xml through ff.xml,
that would contain concatenation of the files that would be in the
directory (wrapped in some top-level tag)? A list of revisions included
could be prepended, so you'd not have to read the whole file to know
whether you have a revision.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051205/f15cdb1c/attachment.pgp