Re: [Monotone-devel] sutures [Re: Time for a release]
On Fri, Dec 26, 2008 at 09:43:17AM -0500, Stephen Leake wrote: Pavel Cahyna pavel.cah...@matfyz.cz writes: I am asking mainly because they could fix a really annoying problem with pluck IIUC: that if you pluck a revision which introduces a file, monotone does not recognize it as the same file as the original one and subsequent pluck which modify this file will fail. See http://lists.gnu.org/archive/html/monotone-devel/2007-08/msg00159.html I don't see how file suture would solve that; there are not two files being sutured. OK, suturing applies only to files, not directories? In the current implementation, yes, but there's no signficant reason for not suturing directories; I just wasn't working on it. I still don't see how suturing helps here. Perhaps you could repeat the example, and add fictional suturing commands that would solve it. I am not sure how would fictional suturing commands look like in general, but basically I mean that the directory a added by the first pluck should be sutured with the directory a added by the second pluck because they are actually the same. The same with the file f in the file-based example. (...) It seems to me that f created by the first pluck and the one patched by the second are really files to be sutured, because they are actually the same file but monotone does not know that. That makes sense, since the user originally only created one file 'f'. However, I don't think they should be sutured; mtn should recognize them as the _same_ file; they have the same node id in the database. Can it? I thought that files added by pluck are as if added independently. Are you sure they have the same node id in the database? with the new file-based example: mtn: conflict: duplicate name 'f' for the directory '' mtn: added as a new file on the left mtn: added as a new file on the right mtn: conflict: file 'f' dropped on the left, changed on the right mtn: error: merge failed due to unresolved conflicts These two conflict messages are conflicting; one says there are two new 'f' files, the other says one was dropped. So mtn is confused. (which is just an example of how much work there is to do on this branch) How to use suturing in your branch? There is not (yet) a user command to suture. See the various 'tests/resolve_duplicate_name_conflict*' tests for the conflict resolutions that are implemented; one of them probably handles this case. It appears that 'pluck' introduces a whole new set of conflicts that need resolution. Although as I said above, I think 'pluck' should be intelligent enough to know that the two 'f' files are in fact the same file in this case. On the other hand, 'pluck' is a somewhat dangerous command in the first place. Can you give a high level description of why you are using it? In particular, using it twice? Well, if you cherrypick a selected change from one branch to another and this change creates new file(s), it is likely that later you will need other changes/fixes to them so you will pluck again a changeset which patches those newly created file(s). My example is a bit artificial bcause it shows two successive plucks. In reality it would look more like: pluck from branchA to branchB, creates file f hack on branchB later: note that branchA has interesting fixes for the file f, pluck again - conflict There are already two tests for the directory variant of the bug: pluck_directory_bug_1 and pluck_directory_bug_2. The first has a commit between the plucks so is closer to a realistic situation, while the second does not have any commits between just like the one I showed here. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] sutures [Re: Time for a release]
On Fri, Dec 26, 2008 at 04:28:53PM -0500, Stephen Leake wrote: Pavel Cahyna pavel.cah...@matfyz.cz writes: On the other hand, 'pluck' is a somewhat dangerous command in the first place. Can you give a high level description of why you are using it? In particular, using it twice? Well, if you cherrypick a selected change from one branch to another and this change creates new file(s), it is likely that later you will need other changes/fixes to them so you will pluck again a changeset which patches those newly created file(s). This is normally handled by branches, and merging the _whole_ branch. You are implying that there are other changes in the source branch that you _don't_ want. Sure, I said cherrypick a selected change, implying that I don't want the others. So the general solution is to design your branches better, so pluck is not necessary. This is not feasible as a general solution, because it would require knowing in advance all the conceivable future uses of the branching scheme at the time one commits a revision. I.e. it would require knowing in advance what changes will anybody ever want to merge separately from the others. Consider sources with a main (developement) branch and release branch(es). You don't want to merge the whole main branch to a release branch, ever. One just carefully selects bugfixes and minor new features from the main branch and applies them to a release branch. pluck would be the way to do it if it DTRT. I do not see how better one could design this branching scheme... BTW - does monotone itself have release branches? I.e. are bugfixes merged to a stable branch instead of requiring everybody to update to the fixed version of the development branch? If you don't have sufficient control over the branching policies, I can see how pluck might be part of a useful workflow. There are already two tests for the directory variant of the bug: pluck_directory_bug_1 and pluck_directory_bug_2. The first has a commit between the plucks so is closer to a realistic situation, while the second does not have any commits between just like the one I showed here. The current pluck implementation builds three rosters, does a merge, computes a changeset from the 'from' revision to the merged, and applies that changeset to the working tree. I don't understand why it doesn't just apply the 'from to to' changeset to the current working directory, as the description of the command implies. The description goes on to say using a merge allows pluck to intelligently handles renames, conflicts and so on; this case demonstrates otherwise :). Maybe it intelligently handles the case when a file common between the two branches is renamed in one of them before the pluck? It would be interesting to test the none-merge approach and see if it solves this current problem and those tests. Interestingly, the existing test pluck_basics demonstrates the same conflict, but implies it is the correct/desired behavior. I suspect there isn't a way to make 'pluck' do what everyone wants of it. I think that making it work like cvs up -j does would be an improvement, even if it proper rename tracking were lost in exchange. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] sutures [Re: Time for a release]
Hello, On Sun, Dec 14, 2008 at 09:22:10AM -0500, Stephen Leake wrote: A few things have to happen before, though: * Had anybody beside the implementor taken a deeper look and tried the new mtn conflicts functionality? Is this ready to ship as is? not to my knowledge; one person used it and aggreed it was an improvement over the current conflict resolution process (which is still there). What is the status of the planned file sutures? Are they related to the new conflicts functionality? I am asking mainly because they could fix a really annoying problem with pluck IIUC: that if you pluck a revision which introduces a file, monotone does not recognize it as the same file as the original one and subsequent pluck which modify this file will fail. See http://lists.gnu.org/archive/html/monotone-devel/2007-08/msg00159.html Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Future of monotone
On Mon, Jan 28, 2008 at 08:51:18PM +0100, Markus Schiltknecht wrote: Hi, Thomas Moschny wrote: Maybe. I wrote it that way for brevity. As some certs may have more logical value fields then others, but should all be put in the same SQL table, you would have to stuff some valued into the same field (from the tables pov), no? Yes, all the information which can be different from cert to cert. That is: 'tag', 'branch', the test result information. But IMO not: 'signer', 'author', 'date', and 'comment' There's something missing. Where would you put the 'comment', 'branch', 'tag' and 'value' data from the table above? Oops, yeah, I forgot about the comment field. Let's try it again: CREATE TABLE new_revision_certs ( hash not null unique, -- consistency checking hash rev_id not null, -- joins with revisions.id name not null,-- name of the cert date not null,-- timestamp of the cert comment, -- optional comment on the cert value not null, -- the tag name or test result value author not null, signer not null, signature not null ); With that table, we would have a reduction to the following certs: - 'commit(-message)' certificate (where changelog - comment and branchname - value) - 'tag' certificate (tagname - value) - 'test-result' certificate. (test result - value) Every cert, even private ones, would then be required to also have a date and an author. Optionally also a comment. In a way, this certainly complicates matters. And I'm not quite convinced, that the above scheme is better than what we have now. However, I certainly agree that we should maintain the connection between the current 'author', 'branch', 'changelog' and 'date' certs, which are mostly created in one atomic step. I thought that monotone philosophy is different and branch certs are independent of commits and mean review/approval - mtn approve. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Re: Re: Re: monotone on alpha, possibly only Debian (was Re: ikiwiki monotone support)
On Thu, Jan 17, 2008 at 05:54:06PM -0500, Jack Lloyd wrote: On Thu, Jan 17, 2008 at 11:42:53PM +0100, Pavel Cahyna wrote: It compiles; ./check output is attached. I interrupted it after 7 minutes when it did not seem to make any progress. If division/modulo is broken as badly as the tests suggest, it's highly likely that one of the power_mod algorithms had gone into an infinte loop. In particular it looks like it is possible with this bug for a % n n -- that is going to cause problems. The most likely files to be miscompiled that would break things in this way are mp_misc.cpp, divide.cpp, then the other mp_* files, then the big_* files (in order of likelyhood). I compiled mp_misc.cpp with -O0, relinked with the rest and all test now pass. Have a look at http://colabti.de/irclogger/irclogger_log/monotone?date=2007-06-15,Fri#l165 too, there is a talk about other compilers mis-optimising botan. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Re: Re: monotone on alpha, possibly only Debian (was Re: ikiwiki monotone support)
On Mon, Jan 14, 2008 at 05:20:40PM -0500, Jack Lloyd wrote: On Mon, Jan 14, 2008 at 10:02:44PM +0100, Pavel Cahyna wrote: I have tried that, but: g++ -pthread -Ibuild/include -O2 -finline-functions -mcpu=ev5 -D_REENTRANT -ansi -Wno-long-long -fpermissive -W -Wall -fPIC -c modules/es_unix/unix_cmd.cpp -o build/lib/unix_cmd.o /usr/include/g++/cwchar:193: error: '::vfwscanf' has not been declared /usr/include/g++/cwchar:199: error: '::vswscanf' has not been declared /usr/include/g++/cwchar:205: error: '::vwscanf' has not been declared /usr/include/g++/cwchar:222: error: '::wcstof' has not been declared *** Error code 1 Argh! Could you do me a favor and confirm/deny that compiling the file containing just the lines: #define _XOPEN_SOURCE 500 #include string fails with the same error? (And also provide me with your exact OS release and compiler versions so I can test this further and hopefully fix whatever it is I have broken). [EMAIL PROTECTED]:~/test$ cat string.C #define _XOPEN_SOURCE 500 #include string [EMAIL PROTECTED]:~/test$ make string.o c++ -O2 -c string.C /usr/include/g++/cwchar:193: error: '::vfwscanf' has not been declared /usr/include/g++/cwchar:199: error: '::vswscanf' has not been declared /usr/include/g++/cwchar:205: error: '::vwscanf' has not been declared /usr/include/g++/cwchar:222: error: '::wcstof' has not been declared *** Error code 1 Stop. make: stopped in /home/pavel/test [EMAIL PROTECTED]:~/test$ gcc -v Using built-in specs. Target: alpha--netbsd Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf4.99.3 --host=alpha--netbsd --target=alpha--netbsd Thread model: posix gcc version 4.1.2 20061021 prerelease (NetBSD nb3 20061125) [EMAIL PROTECTED]:~/test$ uname -sr NetBSD 4.0_RC3 I know you are probably not terribly interested in acting as my personal buildbot, but if you wanted to work around this problem (and hopefully check if this problem with Monotone you're seeing is actually a Botan compilation problem vs something else in lib3rdparty.a), try: ./configure.pl --noauto gcc-netbsd-ev5 which will disable all of the platform-specific code except a small stub for reading /dev/urandom (I'm assuming here the bad code generation, if that is in fact the issue, is in the low level crypto code - in the past this has tended to be true, and also much of the platform-specific code is excised in the version included in Monotone already). $ ./configure.pl --noauto gcc-netbsd-ev5 (error): Arch type ev5 isn't known (try --help) I am using gcc-netbsd-alpha. It compiles; ./check output is attached. I interrupted it after 7 minutes when it did not seem to make any progress. Pavel Beginning validation tests... Testing Block Ciphers: .. Testing Cipher Modes (Encryption): Testing Cipher Modes (Decryption): . Testing Stream Ciphers: Testing Hash Functions: . Testing MACs: .. Testing KDF Algorithms: . Testing S2K Algorithms: ... Testing Encoders/Decoders: Testing BigInt Addition: . Testing BigInt Subtraction: . Testing BigInt Multiplication: ... Testing BigInt Square: ... Testing BigInt LeftShift: . Testing BigInt RightShift: . Testing BigInt Division: . ERROR: operator/ a = 1A923B3406CBE81B093CE418F6A73107F504502B2E3D1B200762FCF6062723DE405CAB0AEA b = 184F03E93FF9F4DAA797ED6E38ED64BF6A1F01 c = 117D3DB34AD005954459BE9ABEDD0E5DEB4EA d = 117D332B4C2D80B9A71CF054E6B545F07B9EE8E2CAF9A54557C66 e = 117D332B4C2D80B9A71CF054E6B545F07B9EE8E2CAF9A54557C66 ERROR: BigInt Division failed test #3 ERROR: operator/ a = 38643020ACA9585367FC9BAB0D8049169F1C3F7B7183 b = 3 c = 12CC100AE43872C677FEDE8E59D56DB235096A7E7B2B d = 12CC100AE43872C677FE33E3AF2A185CDFB4152925D6 e = 12CC100AE43872C677FE33E3AF2A185CDFB4152925D6 .ERROR: BigInt Division failed test #4 ERROR: operator/ a = 119F4F0A35F4EB9A107EF0A5743816D711B8D3D69378F b = D c = 15B06147A4DEABD14F61282E18E29243C70ADD56DCE3 d = 15B06147A4DE0E4776C300CBA2BB2FCD9FA8672F7A6D e = 15B06147A4DE0E4776C300CBA2BB2FCD9FA8672F7A6D ERROR: BigInt Division failed test #5 ERROR: operator/ a = A11E405D5B086A12DFF64F0D4B25631C0FBE6C3C1FC2 b = 5 c = 20394012ABCE7B9D5FFE0FCF756DE09F365948D8D326 d = 20394012ABCE7B9D5FFE0FCF756D13D2698C7C0C065A e = 20394012ABCE7B9D5FFE0FCF756D13D2698C7C0C065A ERROR: BigInt Division failed test #6 .. ERROR: operator/ a = 2A1640FDEBDA73842CF7B19B61F0F8D89AAF836250C2798CD3E0AF43FC9863A6B6BC94AA8F003EAC17E83781E9285273D7E5DE28A857BD84306CD82CFD33D b
[Monotone-devel] Re: monotone on alpha, possibly only Debian (was Re: ikiwiki monotone support)
On Sun, Jan 13, 2008 at 05:45:44PM -0500, Zack Weinberg wrote: On Jan 13, 2008 4:32 PM, Pavel Cahyna [EMAIL PROTECTED] wrote: I use monotone on NetBSD/alpha. The issues I was facing were: 1/ under NetBSD 3, monotone did not compile, because gcc 3.3.x had apparently completely broken exception support. This works in NetBSD 4 with gcc 4.1.2. 2/ I had to disable optimizations in botan, otherwise monotone does not work. What gcc has the Debian release you are speaking about? The problem is with current Debian unstable: $ gcc --version | head -1 gcc (GCC) 4.2.3 20080102 (prerelease) (Debian 4.2.2-5) I'm seeing mysterious testsuite failures when the entire binary is compiled with -O2, and fewer, different mysterious testsuite failures when the entire binary is compiled with -O1. See I had to disable optimizations; -O1 did not work, either. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: monotone on alpha, possibly only Debian (was Re: ikiwiki monotone support)
On Mon, Jan 14, 2008 at 01:04:24PM -0500, Zack Weinberg wrote: On Jan 14, 2008 3:54 AM, Pavel Cahyna [EMAIL PROTECTED] wrote: I'm seeing mysterious testsuite failures when the entire binary is compiled with -O2, and fewer, different mysterious testsuite failures when the entire binary is compiled with -O1. See I had to disable optimizations; -O1 did not work, either. Just to be clear: you get *reproducible* testsuite failures when the entire binary is compiled with -O1, and none when it is compiled with -O0? I haven't run any testsuite. The binary does not work when compiled with -O1. It works without optimizations and also with CXXFLAGS=-mcpu=21164a -g3 CFLAGS=-O2 -mcpu=21164a -g3 MTN_CXXFLAGS=-O2 which ensures that only C++ 3rd party libraries are built without optimizations and everything else is built with -O2. (I was not able to restrict the scope of disabling optimizations further to include only botan.) If so, that is either a compiler bug indeed, or a place where gcc has gotten cleverer with its optimizations and broken an improper assumption in the source code. Either way, the next step, if you're up for it, would be to find out which object file has the bad machine code in it (start from an -O0 build, and one at a time, swap out .o files for ones compiled at -O1, relink and retest; don't neglect lib3rdparty.a). lib3rdparty.a is where the error must be. Unfortunately due to extreme slowness of monotone compilation I don't think I'll have the patience to investigate further in the near future. And unfortunately I've deleted the object files for the compilations to free disk space. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Re: monotone on alpha, possibly only Debian (was Re: ikiwiki monotone support)
On Mon, Jan 14, 2008 at 02:12:38PM -0500, Jack Lloyd wrote: On Mon, Jan 14, 2008 at 08:03:55PM +0100, Pavel Cahyna wrote: lib3rdparty.a is where the error must be. Unfortunately due to extreme slowness of monotone compilation I don't think I'll have the patience to investigate further in the near future. And unfortunately I've deleted the object files for the compilations to free disk space. I don't suppose you could you try building just Botan and seeing if its testsuite passes? (Botan is much less memory intensive to compile than all of Monotone.) I have tried that, but: g++ -pthread -Ibuild/include -O2 -finline-functions -mcpu=ev5 -D_REENTRANT -ansi -Wno-long-long -fpermissive -W -Wall -fPIC -c modules/es_unix/unix_cmd.cpp -o build/lib/unix_cmd.o /usr/include/g++/cwchar:193: error: '::vfwscanf' has not been declared /usr/include/g++/cwchar:199: error: '::vswscanf' has not been declared /usr/include/g++/cwchar:205: error: '::vwscanf' has not been declared /usr/include/g++/cwchar:222: error: '::wcstof' has not been declared *** Error code 1 Stop. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: ikiwiki monotone support
On Sun, Jan 13, 2008 at 03:14:48PM -0500, Zack Weinberg wrote: Incidentally, do you have access to Debian/alpha gear? The #1 outstanding problem with the existing monotone packages for Debian is that they don't reliably build on alpha. I *think* this is a compiler issue but I can't prove it because I don't have access to alpha hardware (debian or otherwise). I use monotone on NetBSD/alpha. The issues I was facing were: 1/ under NetBSD 3, monotone did not compile, because gcc 3.3.x had apparently completely broken exception support. This works in NetBSD 4 with gcc 4.1.2. 2/ I had to disable optimizations in botan, otherwise monotone does not work. What gcc has the Debian release you are speaking about? Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: cvs_import
On Wed, Nov 07, 2007 at 04:53:52PM +0100, Markus Schiltknecht wrote: For everybody interested in the inner workings of that beast, I've updated the wiki: http://www.venge.net/mtn-wiki/CvsImport. There are still some issues, i.e.: * non-UTF-8 filenames (i.e. as in the NetBSD repository). The tree_walker fails on those. Uh, where do we have a non-UTF-8 filename? Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merge bug? - silent data change
Hello, could you please look at http://mtn-host.prjek.net/viewmtn/ufs-trans/revision/info/951b0672754af7e3272775d548c04e3659089bd6 it can be obtained by mtn pull ufs-trans.mtn-host.prjek.net. look at the diff of sys/dev/wscons/wsdisplay_vcons.c (http://mtn-host.prjek.net/viewmtn/ufs-trans/revision/diff/6eb5489725a8c1b10bab48b8341fc5b3e57287a4/with/951b0672754af7e3272775d548c04e3659089bd6/sys/dev/wscons/wsdisplay_vcons.c) it is obviously nonsensical. I think that there is no reason to produce such a difference so it is apparently a merge bug. (comparing with the common ancestor 0795cc5f13f244bba69fd77457427d06026413e0, the file changed only on one side, 6eb5489725a8c1b10bab48b8341fc5b3e57287a4) two other people checked the merge independently and we always arrived at the same revision hash, so I think we can rule out some local corruption. any ideas? Pavel Cahyna ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone fails to detect certain changes in files
On Fri, Aug 24, 2007 at 05:03:15AM +0100, Nuno Lucas wrote: I believe the problem is that I used a small data conversion program that changed the files by mmaping them (it's a small utility to convert files with a MS-DOS codepage to ISO-8859-1 and some few other simple character table-based conversions), and it seems that use-case, with the noatime mount option, doesn't get noticed. Not sure if it really is a bug or something I should expect because of the way my system is setup and the way I work with the mmaped file. Does your small utility use msync()? Apparently without msync, file modification change is supposed to be updated at some point in the future, which might be after monotone checks it. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] pluck failure - successive pluck in the same directory
Hello, I have encountered an annoying problem whit pluck. I try to pluck two revisions. The first one adds a directory, possibly with some files. Pluck succeeds. Tse other revision adds a file under that directory. Pluck of this revision (after the first one) fails with: mtn: warning: orphaned node conflict on node x, dead parent y, name f mtn: warning: resolve non-content conflicts and then try again. mtn: error: merge failed due to unresolved conflicts Besides the fact that the error message is horribly user unfriendly, this should in my humble (and naive) opinion Just Work. I guess it Just Works with cvs up -j... -j... Attached is a test case as requested on #monotone . Pavel #!/bin/sh mtn db init --db=test.db mtn setup --db=test.db --branch plucktest.branch plucktest cd plucktest mtn add . mtn diff mtn commit -m'empty first rev' BASE=$(mtn auto get_base_revision_id) mtn mkdir a mtn commit -m'add a dir' FIRST=$(mtn auto get_base_revision_id) touch a/f; mtn add a/f mtn commit -m'add a file' SECOND=$(mtn auto get_base_revision_id) mtn up -r$BASE mtn mkdir b mtn commit -m'some other random nonconflicting change' mtn pluck -r$FIRST mtn pluck -r$SECOND ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Re: linus talk on git
On Wed, May 30, 2007 at 10:03:31AM +0800, Matt Johnston wrote: On Tue, May 29, 2007 at 09:41:05PM +0200, Pavel Cahyna wrote: I also observe very poor scaling down of the status command. I have a workspace with 17507 files. There is a subdirectory with 17 files. In this subdirectory: $ time mtn status . (...) 71.72s real68.37s user 0.81s system $ time mtn status (...) 91.40s real85.19s user 1.78s system For comparison: the same 17 files, from a CVS repository. cvs has to contact a remote server across the Atlantic. $ time cvs status (...) 8.70s real 0.14s user 0.09s system This is lame. Why should status of 17 files take almost the same time as status of 17507 files? Is inodeprints enabled for that workspace? (mtn refresh_inodeprints.) Yes, I had done this before running the test. In fact this points to one possible scalability problem: there is a 1.5MB inodeprints file and monotone has to read the whole file, even if it needs to know status of only a few files. I doubt this is the main problem here, though. How large are the files/database? The database has 65MB and only one revision, which is the import of everything. Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
