[Monotone-devel] Re: netsync connection info cleanup

[Timothy Brownawell]

On 04/18/2010 01:49 PM, Thomas Keller wrote:

> The following URIs are currently supported:
>
>   mtn://monotone.ca
>   mtn://monotone.ca/monotone
>   mtn://monotone.ca?foo.bar
>   mtn://monotone.ca?foo.bar*/-foo.bar.baz
>   mtn://monotone.ca/monotone?foo.bar
>   mtn://monotone.ca/monotone?foo.bar*/-foo.bar.baz
>   mtn://monotone.ca?include=foo.bar
>   mtn://monotone.ca?include=foo.bar*/exclude=foo.bar.baz
>   mtn://monotone.ca/monotone?include=foo.bar
>   mtn://monotone.ca/monotone?include=foo.bar*/exclude=foo.bar.baz
>
> The first unfortunate thing here is that we have to support two
> different syntaxes, one time you can omit "include=" and replace
> "exclude=" with a "-" and one time these can be given (probably because
> we advertise that people could use weird branch name patterns which
> don't follow the reverse dns scheme almost everybody uses, but this
> doesn't seem to work correct either, try f.e.
> "mtn://monotone.ca/monotone?include=foo/bar/baz*/exclude=foo/bar/baz/bla").
>
> The second unfortunate thing is that the "short" syntax, while being
> less verbose, still needs quoting because of "?" as the query separator
> and "*" for branch expansion.
>
>
> So how should we continue? I think we should pick _one_ syntax and stick
> to that, and I'd vote for the simple one
>
>     mtn://monotone.ca?foo.bar*/-foo.bar.baz

Seems reasonable.

> but with a few modifications so it would look like this:
>
>     mtn://monotone.ca/foo.bar%/-foo.bar.baz
>
> (or explicitely mtn://monotone.ca/+foo.bar%/-foo.bar.baz)
>
> Here no comand line quoting is needed at all and the SQL-like "%"
> wildcard should be recognizable as well.

Is the occasional backslash really that bad? '%' conflicts with 
urlencoding (and '*' would only actually glob things if you have some 
really weirdly named files), and '?' is probably necessary for file/ssh 
sync.

> Secondly, I'd actively deprecate any branch name which does not match
> the following regular expression, i.e. by throwing a warning when a
> branch cert which a different value is created:
>
>     ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$
>
> (test script to play around: http://pastebin.ca/1866605)
>
> This way we ensure that a branch name later does not conflict with the
> URI separator nor with the wildcard character nor with the negation we
> need for branch exclusion in our URI scheme.

I like this.

> Thirdly I'd unify the way includes and excludes are defined for netsync
> commands. I'd deprecate the "SERVER BRANCH [--exclude=PATTERN [...]]"
> options (but would leave them available and convert them to the internal
> representation with "%" as wildcard f.e.) and I'd make the new URI
> available for all commands (currently clone does not support the old
> URIs f.e.).

Sounds good.

> Lastly, the only thing which has not yet been determined is how we can
> represent the server notion for usher - clearly this would conflict with
> the new branch pattern, ie. does
>
>         mtn://monotone.ca/monotone/net.venge.monotone
>
> mean
>
> a) server instance monotone, branch net.venge.monotone - or
> b) default server instance, branches monotone and net.venge.monotone
>
> I can think of several solutions:
>
> 1) "misuse" the user part of the url, ie. mtn://address@hidden/...

Don't we use the user part properly already for ssh sync?

> 2) make the server part mandatory and the first part of the path, ie.
>     mtn://monotone.ca/monotone (or mtn://monotone.ca// or
>     mtn://monotone.ca/default or whatever)

I don't think logic relying on this would play nicely with file/ssh 
sync, where there can be any number of path components.

> 3) use a special character to denote the server instance, f.e.
>     mtn://monotone.ca/~monotone/...

This could work except for our interpreting '~' in file/ssh sync.

4) require a '+' before the inlcude patterns (as shown in your
   later examples). Yeah '+' is used in place of ' ' in URLs, but
   we'd be deprecating use of spaces in branch names anyway.

> Finally, how do other URIs (not based on the mtn:// protocole look like?
> Well, I'd probably simply append them on the original one, like so:
>
>         file:///path/to/db.mtn/+branch/-branch - and
>         ssh://server/~/db.mtn/+branch/-branch - or
>         ssh://server/path/to/remote/db.mtn/+branch/-branch

It looks like a path, but it isn't (entirely) a path. That seems 
horribly counterintuitive and a rather bad idea.

I suppose any '+' in the actual filename would have to be urlencoded (to 
not be taken as a space) and spaces can be done as '%20' as well as '+', 
so it's really only very slightly ambiguous unless someone puts the 
exclude pattern first, but still the lack of clear separation between 
"what we're talking to" and "what we're talking about" is a bit 
disconcerting.

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net