monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: netsync connection info cleanup


From: Thomas Keller
Subject: [Monotone-devel] Re: netsync connection info cleanup
Date: Sun, 18 Apr 2010 20:49:37 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4

Am 18.04.10 04:34, schrieb Timothy Brownawell:
> On 04/15/2010 07:59 AM, Thomas Keller wrote:
>> However there is a bug in our parse_uri() implementation: If no scheme
>> (f.e. mtn://) is given, it treats the string as path rather than as
>> hostname. This leads to the problem that the scheme-less default server
>> setting we store in the db vars is not treated correctly and that a host
>> which is entered by the user is now also parsed wrongly.
>> As I said, I'd rather change the implementation of parse_uri than
>> forcing the user to pull "mtn://monotone.ca" instead of just
>> "monotone.ca"...
> 
> This should work now. parse_uri() will check for things that look like
> only a hostname or ip address and maybe a port, and skip most of the logic.
> 
> It also uses everything before the query string in the db vars, and also
> uses that for the 'peer' string in the network session. This is what
> gets sent to the usher, so giving
>    mtn://monotone.ca/foobar?include=...
> would send "mtn://monotone.ca/foobar" to the usher where it currently
> sends only the hostname (and the normal way of "mtn sy monotone.ca ..."
> would still send just the hostname), which should make it possible to
> use usher with neither wildcard dns nor pattern-based dispatch.

There are still a couple of quirks in the url parsing code - f.e.
path-like (invalid) URIs like the following one are accepted (it will
only fail if no default branch pattern is stored in the DB):

        mtn://monotone.ca/monotone/net.venge.monotone\
                /-net.venge.monotone.guitone

which end up creating completly wrong default server entries. I think we
should define first what we want to allow and how it should look like
here. A small nuisance is f.e. that the "?" in the URI makes problems on
some shells (at least zsh), so you need to quote the complete string.
We've "supported" that use case halfwhat in the past by not using "&" as
query separator, but "/", but I think we can further improve this.

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

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.

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.

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.).


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/...
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)
3) use a special character to denote the server instance, f.e.
   mtn://monotone.ca/~monotone/...


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

What do people think?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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