Am 15.04.2010 04:50, schrieb Timothy Brownawell: >> 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...
I haven't looked into that any further, but I'm putting that on my agenda. Especially since the unit tests still seem to run through this might as well be some kind of weird local / shell error (I'm using zsh here). >> 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. Well, the "server" part would probably be the same as some kind of new --server option we introduce for netsync and this needs to be serialized in the data stream to the server somehow, so of course once the code has been adapted for that, it should just ignore it. We might have to introduce another netsync version for this though. >> 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=... > ? Out of my head I'd have said "use the `include`" argument and let clone check if only one include pattern is given (without expansion syntax), but it might be better to have a dedicated branch argument for that. The interesting question is how this argument is interpreted when used in "normal" netsync operations - especially when further `include` and `exclude` arguments are given. We could make it mutual exclusive, i.e. either let them give a branch argument or a list of include / exclude patterns, what do you think? >>> 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? I don't think thats a good idea, because it puts the burden on the person which manages this branch to keep all tools compilable and running together, and at least for mtn-viz this is a problem, because nobody took up the maintenance from Olivier for this until now. No, I thought that only merging usher into monotone's dir makes the most sense, because its a very useful and probably quite often needed extension for monotone and we could tie both parts better together (f.e. you wouldn't need to use your own copied basicio class). Just as mtnopt is part of the distribution today, usher would be another supplement for multi-database serving. >> 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, Well, I haven't looked at the code and its probably too different from mtn's network code, but I imagined a new "proxy" mode in `mtn serve` which would do just what usher does today. And we'd instantly also get a server-side administrative console within mtn itself to manage the server's running netsync connections and server setups. But thats probably too much and too hard for now... Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. > 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. Out of interest - what does this library do? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel