Re: [Monotone-devel] usher

[Timothy Brownawell]

On 04/14/2010 02:29 AM, Thomas Keller wrote:
> 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.

Makes sense.

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

Huh, that's not good.

...I don't get that error, but it's treating the whole thing as the 
pattern instead of parsing it out. Different behavior, maybe something's 
uninitialized? Something more to look at, I guess...

> 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?

The server can't tell the difference, so it can't know to bail. But then 
it probably doesn't really matter.

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

I suppose that should be
   mtn://monotone.ca/server?branch=...
?

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

Hm. Or do we want a separate branch, with monotone and the various tools 
(usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it?

> Finally, what speaks against integrating usher in monotone's base completly?

As in make it all a single binary? Not sure what the benefit would be, 
and I like the more modular approach. For instance I have a half-written 
usher library in C# somewhere, I imagine that sort of thing would be 
more difficult if usher was baked into monotone.

--
Timothy

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