thread names in urls (Re: Creating a branch other than master using bzr-git)

[Martin Pool]

On Wed, Nov 26, 2008 at 3:41 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> So there are a few forms. And I'd like us to consider that it would be
> nice if an HTTP request could actually return the right thing for the
> given request. Further, we have to consider what it would look like as a
> local path.

That would be good. bzr-git needs something like this, and it is a bit
limiting that thread names are only distinguished by occurring in
particular arguments or options.

I think using ? and # is problematic because they're both shell
metacharacters, and it would be tedious to always explain to someone
why they typed the location in and had everything after the # ignored,
or got a 'no matches' error when they used ?.  You could say 'just
always escape it' but then the escaping will be different between Unix
and Windows.  Also, the fragment is not sent to the server by browsers
-- bzr could send it of course (or deal with it appropriately) but it
will be harder for loggerhead.

I was thinking about perhaps ".../branch/+thread".  "+" has the
advantage of being visually a metacharacter, but not one that has a
strong meaning in either the unix or windows shell, or in http.  It's
used by convention as a short escape for space characters in
filenames, but if I recall correctly (and we should check) this is not
mandated or assumed, just a convention that servers use in mapping
urls to the filesystem.

Anything that lives inside the url or filesystem namespace has the
potential to clash with user-named objects.  (You can have a file
whose relative path is spelled 'http://example.com'...)  I'm sure
someone has committed a file somewhere called +foo but I think it's
reasonably uncommon, and I believe '+' is not allowed on Windows.  We
would need some kind of escape to handle them.  ':' and '@' are
similar.

-- 
Martin <http://launchpad.net/~mbp/>