Re: [Monotone-devel] usher
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:
Re: [Monotone-devel] usher
Am 15.04.2010 09:13, schrieb Thomas Keller: 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). I played around with it further, there are a couple of serious bugs in this feature. Apparently the uri scheme only works if a port (and may it only be the standard port 4691) is given and thats also the reason why the tests don't alert the problem, becase they always run a local mtn instance on the non-standard port. Furthermore, known-servers gets the complete URI instead of just the hostname set when the mtn uri is used: known-servers: mtn://guitone.thomaskeller.biz:4691 f814415176bf04178c64895b19ef99752159626d known-servers: mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone f814415176bf04178c64895b19ef99752159626d This leads to new entries each time the branch pattern changes only slightly and means also that the user is alerted of a new server each time. I don't had the time yet to debug this further, I only re-assured that parse_uri() itself doesn't seem to be the problem, because port-less URIs are tested there and the test succeeds. 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
netsync connection info cleanup Was: Re: [Monotone-devel] usher
Am 15.04.2010 13:33, schrieb Thomas Keller: I played around with [mtn://-style uris] further, there are a couple of serious bugs in this feature. Apparently the uri scheme only works if a port (and may it only be the standard port 4691) is given and thats also the reason why the tests don't alert the problem, becase they always run a local mtn instance on the non-standard port. Furthermore, known-servers gets the complete URI instead of just the hostname set when the mtn uri is used: known-servers: mtn://guitone.thomaskeller.biz:4691 f814415176bf04178c64895b19ef99752159626d known-servers: mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone f814415176bf04178c64895b19ef99752159626d This leads to new entries each time the branch pattern changes only slightly and means also that the user is alerted of a new server each time. I don't had the time yet to debug this further, I only re-assured that parse_uri() itself doesn't seem to be the problem, because port-less URIs are tested there and the test succeeds. I started a new branch (net.venge.monotone.connection_info_cleanup) where I tried to fix some of the issues. mtn://server-style URIs with no port should work already, also the known-servers problem has been fixed. However there is a bug in our parse_uri() implementation: If no scheme (f.e. mtn://) is given, it treats the string as path rather than as hostname. This leads to the problem that the scheme-less default server setting we store in the db vars is not treated correctly and that a host which is entered by the user is now also parsed wrongly. As I said, I'd rather change the implementation of parse_uri than forcing the user to pull mtn://monotone.ca instead of just monotone.ca... I'll try to refactor some of the code afterwards and move the parsing logic (also for include / exclude patterns) into netsync_connection_info. I started already by adding a get_port() method which either returns the default mtn port or a custom port parsed from the argument. 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
Re: [Monotone-devel] usher
On Wed, Apr 14, 2010 at 09:50:08PM -0500, Timothy Brownawell wrote: On 04/14/2010 02:29 AM, Thomas Keller wrote: 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. Usher can permanently monitor the incoming port, and start monotones on specific databases as needed (isn't that the way it works now?) This also means that some of those specific monotones can be started by users working on that server machine, and by users activating monotone by other protocols (such as ssh). There will be occasional mutual exclusion, but all these monotone databases remain mostly accessible. This would not be the case if there was just one binary, and just one permanent monotone process jealously owning its flock of data bases. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] the changelog editor branch is ready for review
2010/4/14 Stéphane Gimenez d...@gim.name Hi, I've been following your discussion, and I tried the nice features in this changlog editor branch. First remark: mtn status ask for my password and it's rather inconvenient (I'm not using ssh agent). Same for mtn commit just after it's invocation and prior to the real commit. Hrm.. I hadn't noticed that but I'll take a look. I wouldn't call it ChangeSet but Parent, simply because it is the parent About this, I find 'ChangeSet: ' really confusing, one could think of '' as an id for the changeset. The good old 'Changes against parent ' looks better to me. In my current workspace I've removed the Parent: lines from the top of the revision header and have used Parent: xxx for the changeset sections which avoids printing the parent lines twice. I'll post an example a bit later. Since you want to know about what users think... See below for what I'd like to see in my editor. I think it's pretty self explanatory and compatible with most of the ideas you came up with. Revision: 595feb9f09d68da0559e4f7ace01f5294090210e Parent: 803a401fd7a2703b5edc416155fbbdba0b287eb4 REMOVE THIS LINE TO CANCEL THE COMMIT * - or fill the following area with certificates - Author: m...@wherever Date: 2010-04-13 17:52:00 Branch: net.venge.monotone.experiment.changelog-editor ChangeLog: - end of editable area - Changes against parent 803a401fd7a2703b5edc416155fbbdba0b287eb4 patched README And, mtn status or mtn log would display the same, just remove '***' and '---' lines (plus empty lines around those). Also, it would be nice if the editor was invoked with option '+13' to position the cursor just after the ChangeLog line. It seems to work with vim, emacs and nano. Interesting. I hadn't noticed this option before but I agree. I have been wondering how annoying it would be to have to reposition the cursor before entering the ChangeLog message and being able to put the cursor right where it needs to go seems very good. This is a simple matter of a change to the lua hook to pass the appropriate arguments. Anyway, whatever you choose, thanks for all this! Thanks for the feedback. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] the changelog editor branch is ready for review
On Tue, Apr 13, 2010 at 1:29 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Derek Scherger de...@echologic.com writes: Presumably someone could write a monotone-commit-mode for emacs and something similar for vim that would allow the editor to prevent you from editing things you're not supposed to. I take the opposite approach in my Emacs front-end; I edit _MTN/log (almost directly), and tell commit to just use it. That means changing the branch, author etc require separate commands (which I have not implemented). Presumably you could pass --author, --date and --branch options? There are commands to enter comment templates from ediff, while reviewing changes. Good to know there are other options. I've been thinking about implementing 'automate log'; the current log implementation in the Emacs front end is horribly inefficient, and has at least one bug that I'm having a hard time fixing. It uses bunches of automate commands to reproduce approximately what 'mtn log' does. Yeah, I think I tried dvc at some point and found it to be quite slow iirc. I should probably try it again though. I still use monotone.el quite often but something better would be good. I've been using magit with git a bit and it seems quite nice as well. The ability to select particular diff hunks interactively can be quite useful, even though it can also be considered bad practice. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
