[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] [RFC] monotone URIs
From: |
Thomas Keller |
Subject: |
[Monotone-devel] [RFC] monotone URIs |
Date: |
Tue, 12 Dec 2006 16:08:47 +0100 |
User-agent: |
Thunderbird 1.5.0.8 (Macintosh/20061025) |
Hi all!
I asked around on IRC if the monotoners ever thought about
monotone-style URIs (so this issue might already have been discussed to
death before my time, if this is so, please ignore this mail), and
apparently the answer was yes, with some "this is needed" addition.
Now for what are those URIs useful? Mainly they're convenient for
newbies and general communication. You don't have to give somebody a
list of configuration details, just one URL which (nearly) contains
everything and you're done. They could also make our interface a little
cleaner as it is now and even introduce new features, more on this in
just a second.
Commands which particularily benefit from URIs are push, pull, sync and
(the upcoming) clone. So how could such an URI look like? A simple form
like this:
$ mtn pull mtn://<host>[:<port>]/<rev-selector>
Note that there is no path to the monotone db file specified, as there
is (to my knowledge) no easy way to run serve for two databases on one
and the same port anyways (never played with usher, though).
'host' is a normal hostname. Note that I didn't include the known
username phrase user@ optionally before the host; this is mainly because
I believe email addresses which we use as key names / user names would
conflict with the @ sign in there. So either we "rewrite" the key here
somehow (like email:address.com) or leave that out completly.
'port' is optional and defaults to monotone's default port 4691
'rev-selector' is a revision selector which is already known for other
commands. Revision selectors should be able combineable (like
a:foo/t:some-tag) and in order to support include/exclude patterns which
are currently separate options in push/pull/sync, the introduction to
negated selectors is needed. So, e.g. to pull all branches beside foo
and bar one would write
$ mtn pull mtn://my.host.net/b:*/!b:foo/!b:bar
Since selectors select revisions and not branches by default, its
obvious that monotone needs some kind of "partial pull" feature for this
in order to work under all circumstances. It should be possible to just
pull one single revision (e.g. always the latest) to do
$ mtn pull mtn://my.host.net/h:my.branch
To avoid too complex URIs a selector without a prefix should default to
a branch rather than "everything" what matches, so
$ mtn pull mtn://my.host.net/my.branch
should be actually the same like
$ mtn pull mtn://my.host.net/b:my.branch
which pulls all revisions for this branch.
Note that all this only addresses netsync communication, e.g. I do not
particularily define a way how to access a certain file inside a certain
revision (do we need this at all and where?).
I've put a wish for this already on the MtnSummit/Ideas page, feel free
to edit / expand that. Other opinions?
Thomas.
--
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.berlios.de
> Music lyrics and more: http://musicmademe.com
- [Monotone-devel] [RFC] monotone URIs,
Thomas Keller <=