monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] usher


From: Thomas Keller
Subject: Re: [Monotone-devel] usher
Date: Wed, 14 Apr 2010 09:29:36 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.3

Hi Tim!

Am 14.04.2010 04:44, schrieb Timothy Brownawell:
>> What happens if somebody pulls or pushes changes with "com.project*" or
>> some other wildcard-using pattern to the server? Would this fail because
>> neither server would be able to respond? What would happen for a pattern
>> like "{com.project-1,com.project-2}"?
> 
> Both would fail. It looks for servers where the server pattern is an
> initial substring of the client's include pattern, and IIRC uses the
> matching one with the longest pattern in the case of multiple matches.

Ok, I thought something similar.

>> What is the status of usher currently anyways? I haven't seen an
>> official release of it (no tags at least), but it seems to be proven
>> stable over the last couple of years. If there would be an offical
>> release, packagers would be able to pick it up easier and could provide
>> it as tool on top of monotone.
> 
> I use a slightly modified version for mtn-host.prjek.net (it gets the
> list of servers by listing a directory instead of directly from a config
> file), and it seems to work well enough. This also uses only the
> hostname to select which server to use, like if you were to only specify
> "host" and not "pattern" line in the config file.
> 
> The pattern-based dispatch really should be more intelligent I guess,
> expand all the braces and make sure all the parts match the same server
> (and just make for example having "com" on one server and "com.project"
> on another be a config error). 

While the DNS-/hostname-based approach seems to be the best way to
distinguish different projects, its not always possible to configure
that easily, even though only a wildcard DNS entry is needed. I'm
currently (seriously) looking into integrating mtn in indefero and they
won't set up a DNS entry just to support another VCS, so pattern
matching is (for now) the only possibility. But given the name clash you
describe above its probably not the best.

Maybe there is a third way, which would require changes in monotone
though: what about picking the database / server to use for netsync
directly from the client? I vaguely remember that we introduced an URL
schema in monotone a couple of versions ago (0.40 or so) and while its
nowhere documented beside in NEWS (not even functional in 0.47 for me
anymore, I get a network error "service name resolution failed for:
mtn", but the lua test still seems to run through), it looks like it
could be used for that:

   mtn://monotone.ca?include=...&exclude=...

What about expanding this to

   mtn://monotone.ca/server?include=...&exclude=...

and adding some logic the normal mtn server to bail out if the /server
part is found for a non-usher server?

I'd also look into adding support for these kind of URIs to mtn clone,
which currently still needs a branch argument.

> I suppose this isn't that big a deal,
> might as well just tag current head as a release I guess?

Thats right - I also wondered if its worthwhile to merge-into-dir usher
to the main monotone tree and include it in the base distribution. Usher
makes only very very little sense without monotone and if its packaged
right with monotone, you would not need to spend time setting up a web
page, bug tracker, etc pp, but the development of both could be
synchronized.
Finally, what speaks against integrating usher in monotone's base completly?

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]