[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: netsync connection info cleanup

From: Timothy Brownawell
Subject: [Monotone-devel] Re: netsync connection info cleanup
Date: Tue, 27 Apr 2010 18:42:56 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100411 Icedove/3.0.4

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

The following URIs are currently supported:


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.

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


Seems reasonable.

but with a few modifications so it would look like this:


(or explicitely mtn://

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:


(test script to play around:

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



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:// (or mtn:// or
    mtn:// 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.

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/ - and
        ssh://server/~/ - or

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.


Free public monotone hosting:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]