[Monotone-devel] [RFC] M.T. phone home
Hey all, I've been thinking some more about a feature that might be controversial, so want to consult with the community before going forward. There are some old and relatively incoherent notes here: http://venge.net/monotone/wiki/CarrotAndStick But the basic problem is this: it would be really useful if we had a way to get more metrics on how people use monotone in real life. For instance: -- what commands do people run most often? (maybe they should have the shortest names, and appear earliest in the docs, and get the most optimization effort) -- are there commands that people often run in quick succession? (maybe there should be sugar to make that more convenient) -- what percentage of merges involve conflicts? -- what percentage of merges involve messy tree-rearrangement conflicts? -- do selectors actually get used? -- what are the real-world statistics for trees? E.g., for benchmarking, it can matter a lot how many files are in a tree, how deep the directory structure is, how many files are changed per commit, etc., and we don't know what numbers are actually representative. ...and so on. The obvious solution is to, well, start measuring them. It's straightforward enough for monotone to start collecting data like this (spooling it to a file in ~/.monotone, say). It's even straightforward enough to make sending these files in to add to our statistics a painless operation. But, any app that records information about what you do and then phones home is going to risk being controversial! So, my question here is, what people think about this, and what sort of precautions need to be taken if we do this. My current thought is that firstly, we never ever record any user names, host names, key names, branch names, tag names, file names, or, of course, file contents. Given this, the only way I can think of that we could identify what was actually being worked on was if we, say, recorded commit times or tree sizes and compared that to public project histories --- but presumably people working on public projects wouldn't care about that, because, well, they're public anyway? My thought is that the people that are more likely to be worried about this are people using monotone commercially. It would be useful to record the time each command is run at, so we can look at histories of use as well as simple frequencies (e.g., for the which commands are run in sequence? question mentioned above). To make this data even more effective, it would be useful to include a persistent random cookie with each bundle of data, so that multiple bundles from the same person could be knitted together into a single history. This may be controversial, though, even though it does not involve personally identifiable data! What do people think? The next question is how this is presented to the user. Obviously, there would be some way to disable the functionality entirely. (This is needed for technical reasons as well, see the NTP kiss-of-death packet for comparison.) The UI for if it is not disabled is not entirely clear -- the most conservative option would be for it to ship disabled, and only be enabled by people who came across a description of it hidden in the manual somewhere, and then took action to turn it on. If we make it _this_ obscure, though, then most people are not going to even bother, which could make the whole exercise pointless. An intermediate version would be something like: -- by default, records data but doesn't do anything with it -- after recording X bytes, starts (occasionally or always?) giving the user a little hint hey, I have some data, maybe decide if I should send it -- after recording, say, 2X bytes without any response, disable the functionality and delete the log file (so as not to waste their hard-drive space). If someone _does_ decide to enable the functionality, then we could, how about, whenever they run push/pull/sync, if we have X bytes of data, post them back to us. The biggest problem here is making sure that this doesn't interfere with use otherwise -- like, if they're not actually connected to the network, we don't want to freeze trying to resolve venge.net! Perhaps the answer is to perform the actual operation first, and then print a message saying what we're trying to do, and that if it freezes or they're just feeling ornery that they can just hit C-c to skip it (and mtn whatever to disable it in the future). Obviously, we would never send in any data without the user having explicitly taken some action to allow it. Finally, once we have the data... I would very much like to make all the data simply available publically; keeping track of who exactly was allowed to access it would be a big pain, reduce the usefulness, and would mean that e.g. people working on other VCSes or studying FOSS generally couldn't use it. So that's one of the reasons that the list above is so careful about not
Re: [Monotone-devel] [RFC] M.T. phone home
On 8 jun 2006, at 10:45, Nathaniel Smith wrote: But the basic problem is this: it would be really useful if we had a way to get more metrics on how people use monotone in real life. For instance: -- what commands do people run most often? (maybe they should have the shortest names, and appear earliest in the docs, and get the most optimization effort) -- are there commands that people often run in quick succession? (maybe there should be sugar to make that more convenient) -- what percentage of merges involve conflicts? -- what percentage of merges involve messy tree-rearrangement conflicts? -- do selectors actually get used? -- what are the real-world statistics for trees? E.g., for benchmarking, it can matter a lot how many files are in a tree, how deep the directory structure is, how many files are changed per commit, etc., and we don't know what numbers are actually representative. ...and so on. Would it also be possible to see if people follow the 'intended philosophy'? I mean, on situations where monotone barfs something about tmp directories, orphaned nodes, rename conflicts and what have you, do they bail out and start over or do they 'use the force' to get back on track? The above reminds me of the openlogging 'feature' that bitkeeper had/ has. Apart from what you described above, the main usefulness (to me) was to have a 'unified activity' view of the repositories. If people were working on stuff locally, experimenting, but not pushing yet, it showed me that and I was able to contact those people saying hey, i see you're working on something which is also done by those two guys there, perhaps you want to set up some form of communication In general, the sending of the 'activity log' has a balance which tips over to the 'monotone hackers' on short term, users presumably benefit from the conclusions drawn from those logs by having a better monotone longer term. If there would be a way, perhaps by not only sending the activity log to a 'monotone place', but also allowing users to set up their own 'project home'. Having information about your project's activity without having to go through the trouble to teach everyone how to 'serve' monotone (so revs can be exchanged directly) can be very useful. marcel -- Marcel van der Boom HS-Development BV -- http://www.hsdev.com So! webapplicatie framework -- http://make-it-so.info smime.p7s Description: S/MIME cryptographic signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] M.T. phone home
On Thu, Jun 08, 2006 at 11:00:47AM +0200, Marcel van der Boom wrote: Would it also be possible to see if people follow the 'intended philosophy'? I mean, on situations where monotone barfs something about tmp directories, orphaned nodes, rename conflicts and what have you, do they bail out and start over or do they 'use the force' to get back on track? Umm, I dunno... depends on whether we can write code to detect whether they are using the force or not. I guess if we saw a lot of merge with exotic conflicts followed by calls to db init that would be a clue... However, what I really want to know now is how to make this kind of feature Non-Evil and ideally even Non-Controversial; we have plenty of time to work out exact details of how we analyze the data etc. The above reminds me of the openlogging 'feature' that bitkeeper had/ has. Apart from what you described above, the main usefulness (to me) was to have a 'unified activity' view of the repositories. If people were working on stuff locally, experimenting, but not pushing yet, it showed me that and I was able to contact those people saying hey, i see you're working on something which is also done by those two guys there, perhaps you want to set up some form of communication In general, the sending of the 'activity log' has a balance which tips over to the 'monotone hackers' on short term, users presumably benefit from the conclusions drawn from those logs by having a better monotone longer term. If there would be a way, perhaps by not only sending the activity log to a 'monotone place', but also allowing users to set up their own 'project home'. Having information about your project's activity without having to go through the trouble to teach everyone how to 'serve' monotone (so revs can be exchanged directly) can be very useful. I think this is pretty orthogonal, since the emphasis of the system I'm talking about would be exactly to make it _hard_ (ideally, impossible) for anyone to figure out what was actually being worked on from just the data it gathered :-). It's also not clear to me how this would work; if people aren't pushing their code, why would they be pushing their logging info? (With BK, of course, the difference between pushing code and pushing logging info is that the latter always works, while the former involves merging branches that perhaps should not be merged. But monotone works hard to make pushing code orthogonal to project-level decisions like that, so pushing code and pushing logging are pretty much the same.) -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] M.T. phone home
Nathaniel Smith wrote: ... I'll probably start implementing this in the next few weeks (assuming that the response to this isn't an overwhelming this would be a horrible violation and can't be done at all!), but really want to make sure that we get the details right so that people don't feel spied-on or otherwise uncomfortable. So, comments? IMHO, the user should be able to disable recording per-repo, and the information sent should be human-readable. Just my two c. Riccardo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [RFC] M.T. phone home
My general take on this: * I don't mind so much information is gathered, but I would appreciate being able to see exactly what is sent * Branch names are sensitive because we branch per feature / bug fix with the bug identifier in the branch name * Directory/file names are sensitve for more or less the same reason Now let me elaborate why this is sensitive, if a client of hours could put in google his bug identifier and the google search would show information regarding monotone activity of us related to this bug, that is BAD. (Especially because the can use that foothold to gather information about other bugs that are worked or NOT worked on). I don't mind necesarily so much if monotone developers knows our monotone usage. Of course the same happens with file/directory names. It isn't to hard to guess a directory/file name. And if this allows someone to discover our commit patterns related to files/directories is not something I feel comfortable with. In the same vein: * Name of keys, server, DB etc. Sensitive. If everything is anonymous, and it is hard to link the information back to a project I do not mind so much. I am not really afraid of someone spending weeks to figure out if he can discover our usage of monotone by looking through lots of anonymous and obfuscated names. On the implementation/usage part. I have a few questions/remark: 1 - The location of storing this data needs to be choosen carefully, because we run a monotone server where we do not use HOME, but specify the config file on the command line. (We are using an older version, I don't know how the new key storage works yet.) 2 - The server, I never run any command on it by hand. So I will never see a request to phone home. (Might be that you are not interested in this data at all.) 3 - I run monotone for the most part through my emacs front end. I would not like it to spring me a question when I run it that way, because it would confuse emacs. 4 - And, as you of course realize, but let me state the obvious, failure to send should not interfere with monotone usage. There is undoubtedly much more, but this is it for now. Wim Oudshoorn ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] M.T. phone home
On Thu, Jun 08, 2006 at 01:45:07AM -0700, Nathaniel Smith wrote: -- after recording X bytes, starts (occasionally or always?) giving the user a little hint hey, I have some data, maybe decide if I should send it Failure to reply should not interfere with use. In particular, it should not wait indefinitely for a reply. Think of monotone being run in an unattended script. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] M.T. phone home
On Thu, 2006-06-08 at 01:45 -0700, Nathaniel Smith wrote: It would be useful to record the time each command is run at, so we can look at histories of use as well as simple frequencies (e.g., for the which commands are run in sequence? question mentioned above). This would really only need, say, the time of day, rather than a full timestamp. In case full timestamps would worry (some) people. To make this data even more effective, it would be useful to include a persistent random cookie with each bundle of data, so that multiple bundles from the same person could be knitted together into a single history. This may be controversial, though, even though it does not involve personally identifiable data! What do people think? Ask them when asking permission to send it? The next question is how this is presented to the user. Obviously, there would be some way to disable the functionality entirely. (This This would have to be available as both a compile-time option, and a run-time (db var, or item in $CONFDIR?) option. I'm sure we have some users who wouldn't want this functionality anywhere near their code. is needed for technical reasons as well, see the NTP kiss-of-death packet for comparison.) The UI for if it is not disabled is not entirely clear -- the most conservative option would be for it to ship disabled, and only be enabled by people who came across a description of it hidden in the manual somewhere, and then took action to turn it on. If we make it _this_ obscure, though, then most people are not going to even bother, which could make the whole exercise pointless. An intermediate version would be something like: -- by default, records data but doesn't do anything with it -- after recording X bytes, starts (occasionally or always?) giving the user a little hint hey, I have some data, maybe decide if I should send it Some anonymous usage statistics have been collected in $CONFDIR/stats. Run mtn usage-stats send to send this to the developers. The database of collected statistics is publicly available at http://venge.net/monotone/usage-stats/ Run mtn usage-stats autosend to send this to the developers, and automatically send further stats as they are collected. Run mtn usage-stats disable to disable statistics collection. Run mtn usage-stats show to show what would be sent. -- after recording, say, 2X bytes without any response, disable the functionality and delete the log file (so as not to waste their hard-drive space). If someone _does_ decide to enable the functionality, then we could, how about, whenever they run push/pull/sync, if we have X bytes of data, post them back to us. The biggest problem here is making sure that this doesn't interfere with use otherwise -- like, if they're not actually connected to the network, we don't want to freeze trying to resolve venge.net! Perhaps the answer is to perform the actual Async dns libraries are nice, we could start resolving when the command was run, and cancel if there's no reply by the time were done... operation first, and then print a message saying what we're trying to And stating that we're only doing it because we beleive they specifically enabled it. do, and that if it freezes or they're just feeling ornery that they can just hit C-c to skip it (and mtn whatever to disable it in the future). Obviously, we would never send in any data without the user having explicitly taken some action to allow it. And we should mention what we're doing, and that they specifically allowed it, and how to disable it, every time we send anything. Finally, once we have the data... I would very much like to make all the data simply available publically; keeping track of who exactly was allowed to access it would be a big pain, reduce the usefulness, and would mean that e.g. people working on other VCSes or studying FOSS generally couldn't use it. So that's one of the reasons that the list above is so careful about not gathering personally identifiable information. This is yet another thing I'd like feedback on, though. Publicly available is good. It also means we don't have to worry about security compromises and resulting annoyed users. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: 0.26 error
On Thu, Jun 08, 2006 at 07:40:23AM -0400, Shawn Samuel wrote: Nathaniel, Multiple developers on my team are hitting this, and at least myself and one other person are seeing this when no files are being changed and no other activity is happening in the working tree. Are fixes like these done on their own branches? i.e. I would like to be able to build a monotone 0.26+ with just this patch as one of my developers seems to be hitting it on every update right now. The fix referred to just improves the printed message, see http://viewmtn.angrygoats.net/revision.psp?id=5d681427e93999bd5c47b8209abb589c13d760db Given it's happening often, and there were problems with files with differing cases, that might be a plausible cause? If 'foo' gets written, then 'Foo' gets written over the top, I think it could trigger this. It might be worth checking over the file list (mtn ls known) to see if there're any files like that? Matt ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Removing a revision from a branch
I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? Thanks, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
Shaun Jackman [EMAIL PROTECTED] wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? Yes. As long as the change has not propagated to other databases via synchronization, you can: $ mtn -d DATABASEPATH db kill_rev_locally REVISION If it has already propagated to other databases, you can try to coordinate with everyone to do the same. Alternatively, if there is only one parent to REVISION, use ``mtn disapprove REVISION''. Here's the text description from the monotone manual: `monotone disapprove ID' This command records a disapproval of the changes between ID's ancestor and ID. It does this by committing the inverse changes as a new revision descending from ID. The new revision will show up as a new head and thus a subsequent `merge' will incorporate the inverse of the disapproved changes in the other head(s). Conceptually, `disapprove's contract is that disapprove(A) gives a revision B such that whenever B is merged with a descendent D of A the merge will result in what D would have looked like if A had never happened. Note that as a consequence of this contract the `disapprove' command only works if ID has exactly one ancestor, since it hasn't been worked out how to generate such a descendent in the multi-ancestor case. Essentially, it's quite hard to get rid of a revision once it has been copied to other databases. This is the next best thing. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
On 6/8/06, Chad Walstrom [EMAIL PROTECTED] wrote: Shaun Jackman [EMAIL PROTECTED] wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? Yes. As long as the change has not propagated to other databases via synchronization, you can: $ mtn -d DATABASEPATH db kill_rev_locally REVISION I didn't explain my problem correctly. The revision is good, and I do want it to exist, but it accidentally has two `branch' certs and two `date' certs. One is for the branch is should be in, and I have no idea where the other came from. I'd like to remove the spurious branch cert. This error hasn't made it into any other databases. I suppose want I want is a `db kill_cert_locally' command. Would the cert be specified by revision/name/value? The output of `ls certs' showing my problem follows. Cheers, Shaun $ mtn ls certs e529 mtn: expanded selector 'e529' - 'i:e529' mtn: expanding selection 'e529' mtn: expanded to 'e529f44eef1fc60ef5e66cbe545ec43513222970' Key : [EMAIL PROTECTED] Sig : ok Name : author Value : Shaun Jackman [EMAIL PROTECTED] Key : [EMAIL PROTECTED] Sig : ok Name : branch Value : busybox Key : [EMAIL PROTECTED] Sig : ok Name : branch Value : busybox-sdj Key : [EMAIL PROTECTED] Sig : ok Name : changelog Value : * .config: New file. Key : [EMAIL PROTECTED] Sig : ok Name : date Value : 2006-06-05T20:48:43 Key : [EMAIL PROTECTED] Sig : ok Name : date Value : 2006-06-05T20:51:15 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
On Thu, 2006-06-08 at 10:23 -0600, Shaun Jackman wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? No, you have to use 'db execute'. Make a copy of your db, then run mtn db execute delete from revision_certs where id = 'revid' and name = 'branch' (remove all branch certs from that revision), then mtn approve revid -b branch-you-want (put back the one you want). Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
On 6/8/06, Timothy Brownawell [EMAIL PROTECTED] wrote: On Thu, 2006-06-08 at 10:23 -0600, Shaun Jackman wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? No, you have to use 'db execute'. Make a copy of your db, then run mtn db execute delete from revision_certs where id = 'revid' and name = 'branch' (remove all branch certs from that revision), then mtn approve revid -b branch-you-want (put back the one you want). Thanks! Your advice worked perfectly. Incidentally, the branch still has two `date' certs. I can figure out on my own how to remove one of them with `db execute' command. What could possibly cause two date certs to be created? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: 0.26 error
On Thu, Jun 08, 2006 at 07:40:23AM -0400, Shawn Samuel wrote: Nathaniel, Multiple developers on my team are hitting this, and at least myself and one other person are seeing this when no files are being changed and no other activity is happening in the working tree. Are fixes like these done on their own branches? i.e. I would like to be able to build a monotone 0.26+ with just this patch as one of my developers seems to be hitting it on every update right now. Well, here's a minimal patch against 0.26 (untested, but dead simple): --- work.cc b4e65a058f65062894d119f77e9ab0866b05a4c5 +++ work.cc 7880412b85010f0d55baf15f5c32077e3115c15e @@ -999,7 +999,7 @@ calculate_ident(pth_unsplit, curr_id_raw, app.lua); file_id curr_id(curr_id_raw); E(curr_id == old_id, -F(content of file '%s' has changed, not overwriting)); +F(content of file '%s' has changed, not overwriting) % pth_unsplit); P(F(updating %s) % pth_unsplit); file_data dat; It won't solve your problem on its own, since the bug you are hitting is itself in the error-reporting logic -- so with the bug fixed you'll just get a more useful error message :-). But that might hint at what's actually going wrong, since it will tell you what path is causing the problem. My guess is that like Tim said, it's some sort of issue with the doppelganger files you reported earlier. If so, your history is intact and everything, it's just that current versions of monotone aren't very clever about handling it on case-insensitive filesystems; so if you can just clean it up and get past it (e.g. by using checkout instead of update, or cleaning it up and then updating to a cleaned up revision might work?), then you should be fine until we have a more proper fix. Sorry for the inconvenience! Let us know if that helps at all; hard to give more specific advice without knowing more details of the problem. -- Nathaniel -- ...these, like all words, have single, decontextualized meanings: everyone knows what each of these words means, everyone knows what constitutes an instance of each of their referents. Language is fixed. Meaning is certain. Santa Claus comes down the chimney at midnight on December 24. -- The Language War, Robin Lakoff ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] M.T. phone home
On 6/8/06, Nathaniel Smith [EMAIL PROTECTED] wrote: I've been thinking some more about a feature that might be controversial, so want to consult with the community before going forward. There are some old and relatively incoherent notes here: http://venge.net/monotone/wiki/CarrotAndStick One thing that I believe is still missing (haven't checked the last changelogs) is something like a mtn db optimize, which could run VACUUM and ANALYSE on the database as a minimum, and maybe some optimization of the history (like optimize for the most checked out branches or whatever other optimizations thingies). My idea is that this command is a good place to implement that phone home behaviour, and I don't think it should EVER be automatic (unless with some obscure config option that only devels will know about). Without thinking too hard on it, I would implement that mtn db optimize command and add a --phone-home sub-comand. If the --phone-home option is not given, then a message could be shown. Something like this (just to get an idea): fake_output $ mtn --db mydb.db db optimize [...some stats about the optimizing process...] Done. Some statistical data about the program usage was collected. Please help the monotone developers improve this application (and the 'optimize' command) by posting this information. This data is fully anonymous and you can inspect it with ---view-stats-data-to-post-to-web [you decide the name]. Please run mtn --db repo --phone-home to post the info. $ /fake_output Just my 2 cents, ~Nuno Lucas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Snapshot builds for Debian unstable
Sweet! Richard Levitte - VMS Whacker wrote: I've build monotone .deb's from a combination of the following branches for a while: net.venge.monotone - the main development branch net.venge.monotone.debian - additional debian control files net.venge.monotone.levitte.select-heads-off - additional H: selector It results in two packages, monotone and monotone-server. Today, I set up a apt-get'able repository so the snapshot would be easy to install. Anyone is welcome to use it. All that's needed is the following in /etc/apt/sources.list: # LP archive deb http://guardian.lp.se/debian unstable/ deb-src http://guardian.lp.se/debian unstable/ I do those builds at irregular but normally frequent intervals (at least twice a week), a little depending on what happens with monotone development. Oh, the only architecture that I currently support is i386 (oh, and all), because that's what I build on. If someone wants to support other architectures as well and make it available through my repo, please let me know and I'll see what I can arrange. I sign the packages with the following key: : ; gpg --list-keys levitte pub 1024D/F709453B 2003-10-20 uid Richard Levitte [EMAIL PROTECTED] uid Richard Levitte [EMAIL PROTECTED] uid Richard Levitte [EMAIL PROTECTED] sub 2048g/E6E1C65B 2003-10-20 It's up to you to find the key and check the fingerprint in whatever manner you like. If you look around, you know how to find me, just don't expect me to comply when I'm in the middle of sleeping :-). Enjoy! Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Matthew A. Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
