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
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
