Re: [Monotone-devel] time for a release?
Markus Wanner mar...@bluegap.ch writes: How much time do we need to be able to release? Any pending items somebody absolutely wants to get in? I've updated my Cygwin on XP; I'm compiling the nvm.lua-5.2 branch now; Cygwin still has Lua 5.1.4, so I hope that's compatible. I'll work on updating INSTALL_windows_cygwin.txt to match. I'll also work on updating INSTALL_windows_native.txt to the latest versions, and test on XP. I can also test on Cygwin and mingw on Windows 7 64-bit (and Windows 7 32 bit, I assume, if the 64 bit fails). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
Stephen Leake stephen_le...@stephe-leake.org writes: Markus Wanner mar...@bluegap.ch writes: How much time do we need to be able to release? Any pending items somebody absolutely wants to get in? I've updated my Cygwin on XP; I'm compiling the nvm.lua-5.2 branch now; Cygwin still has Lua 5.1.4, so I hope that's compatible. That compiled fine, but when running the tests, it seemed to hang in one. More later. I can also test on Cygwin and mingw on Windows 7 64-bit (and Windows 7 32 bit, I assume, if the 64 bit fails). Cygwin is only 32 bit. On Windows 7 (64 bit machine, 32 bit Cygwin), I'm getting 4 failures. More details later. On to Mingw. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
In message 4f970a86.5040...@bluegap.ch on Tue, 24 Apr 2012 22:18:14 +0200, Markus Wanner mar...@bluegap.ch said: markus Hi, markus markus quite a few fixes went in since monotone 1.0, including the recent fix markus for compatibility with Botan 1.10 (which got released in June 2011). So markus I'm thinking it's about time for a release. markus markus How much time do we need to be able to release? Any pending items markus somebody absolutely wants to get in? I think it would be smart to have Richard Hopkins Lua 5.2 adaptation (currently present in net.venge.monotone.lua-5.2) included. I'm just about to make a distcheck on that branch. (btw, Richard, it fixes issue 206 ;-)) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
Markus Wanner mar...@bluegap.ch writes: Hi, quite a few fixes went in since monotone 1.0, including the recent fix for compatibility with Botan 1.10 (which got released in June 2011). So I'm thinking it's about time for a release. Yes, it is time. How much time do we need to be able to release? Any pending items somebody absolutely wants to get in? https://code.monotone.ca/p/monotone/ is down, so I can't search for bugs. I have a fix for nfs mounted directories in mtn workspaces that I'd like to get in; it just needs a little more testing. The manual could use some attention as well; I recently tried to find the discussion of renaming branches by propagating to a new branch, and couldn't find it! There are also some cross references missing. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 05.06.2010 23:24, schrieb Thomas Keller: Am 05.06.10 18:26, schrieb Zack Weinberg: On Sat, Jun 5, 2010 at 4:59 AM, Thomas Keller m...@thomaskeller.biz wrote: I assume you meant /dev/nul instead of /dev/null there? No, I meant /dev/nul - try GNU patch and tamper the patch file to +++ /dev/nul (which is of course wrong) - then you'll see that empty files are kept and are only removed explicitely with -E. This is what I mean - we'd tamper the test if we add -E, because then we just test GNU patch to correctly interpret the -E option, but not to automatically remove the file if it is empty _and_ has the target /dev/null. Oh, I see what you mean. Well, is the exact behavior of the system 'patch' utility the focus of the test? I'm kinda inclined to doubt it, but I have lost the message that says which test we're talking about here... The test is diff_patch_drop and IMHO it exactly tests the proper removal of the files at the end. If not we could / should probably just remove the last two checks. I have changed the test that it now executes patch with -E on BSD's and that it only checks for a removed directory on non-BSD's (apparently GNU patch is much more aggressive). FreeBSD and openBSD now pass this test - the openBSD bot is still broken with three other tests though. 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] Time for a release
Am 04.06.2010 16:26, schrieb Thomas Moschny: Am Fri, 04 Jun 2010 01:45:44 +0200 schrieb Thomas Keller m...@thomaskeller.biz: While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like to give my release manager hat to somebody else afterwards, so I can concentrate on other things a bit more. I'm not out of the world, so whoever wants to take the job can of course count on my help. Thanks for doing the job for a so long time now! Thank you all for being patient with me :) Doing releases does not involve much - the process is fairly good documented. Perhaps the most important skills are a bit of a passion for the software and some accuracy :) So, who's up for the job? If no one else is interested, I'd volunteer. Since nobody else spoke up over the last couple of days, you've been automatically selected ;) - thanks for taking the opportunity! 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] Time for a release
Am 05.06.10 01:26, schrieb Zack Weinberg: On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote: So, what should we do here? The addition of -E for all other unices would mean that we'd tamper the test. I distinctly remember having to add -E on SunOS, and I would not be at all surprised if, well, anyone else who doesn't use GNU patch had the same behavior. Therefore I think we should unconditionally add -E. (change a test diff to use /dev/nul instead of /dev/nul, f.e., to see the effect - the file is no longer removed on compliant systems). I assume you meant /dev/nul instead of /dev/null there? No, I meant /dev/nul - try GNU patch and tamper the patch file to +++ /dev/nul (which is of course wrong) - then you'll see that empty files are kept and are only removed explicitely with -E. This is what I mean - we'd tamper the test if we add -E, because then we just test GNU patch to correctly interpret the -E option, but not to automatically remove the file if it is empty _and_ has the target /dev/null. By the way, standard English is e.g. not f.e. It expands to exempli gratia. Yes, that's Latin. I blame the French. I remember somebody has told me that a couple of years ago (was it you?) - I forget it from time to time - I should remember it now for the next couple of months, though :) 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] Time for a release
Am 05.06.10 18:26, schrieb Zack Weinberg: On Sat, Jun 5, 2010 at 4:59 AM, Thomas Keller m...@thomaskeller.biz wrote: I assume you meant /dev/nul instead of /dev/null there? No, I meant /dev/nul - try GNU patch and tamper the patch file to +++ /dev/nul (which is of course wrong) - then you'll see that empty files are kept and are only removed explicitely with -E. This is what I mean - we'd tamper the test if we add -E, because then we just test GNU patch to correctly interpret the -E option, but not to automatically remove the file if it is empty _and_ has the target /dev/null. Oh, I see what you mean. Well, is the exact behavior of the system 'patch' utility the focus of the test? I'm kinda inclined to doubt it, but I have lost the message that says which test we're talking about here... The test is diff_patch_drop and IMHO it exactly tests the proper removal of the files at the end. If not we could / should probably just remove the last two checks. 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] Time for a release
Am 04.06.2010 05:53, schrieb Derek Scherger: On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller m...@thomaskeller.biz wrote: 206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52) 301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22) Both tests fail with restriction includes unknown path on foo2 / foo1. This is still an open issue. I'd like to see the detailed tester.log files for these but I have no idea how to get them. If someone can point me in the right direction I'll take a look. Directly from the bot: http://monotone.ca/~mtn-buildbot/x86-openbsd/tester_dir.tar 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] Time for a release
Am 04.06.2010 05:46, schrieb Derek Scherger: On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller m...@thomaskeller.biz wrote: I've just talked with Thomas Moschny on IRC and I listened again to his and other people's concerns about switching too fast to 1.0. I think the concerns are reasonable, so we've discussed this issue and concluded the following: * The next version of monotone will be named 0.99 and will be the last version before the final 1.0.0 is out I agree with the general concern that we've had a few branches land lately. I wouldn't be surprised in the least to hear some screaming when people start using the new changelog editor functionality for example. Also, restrictions have been changed a bit, diff has also changed slightly, etc. Hopefully these changes are all good and generally liked, but the idea of changing a bunch of behaviour and then releasing 1.0 shortly afterwards seems a bit questionable. See it this way: We're just switching to a different versioning scheme :) 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] Time for a release
Am Fri, 04 Jun 2010 01:45:44 +0200 schrieb Thomas Keller m...@thomaskeller.biz: While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like to give my release manager hat to somebody else afterwards, so I can concentrate on other things a bit more. I'm not out of the world, so whoever wants to take the job can of course count on my help. Thanks for doing the job for a so long time now! Doing releases does not involve much - the process is fairly good documented. Perhaps the most important skills are a bit of a passion for the software and some accuracy :) So, who's up for the job? If no one else is interested, I'd volunteer. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 03.06.10 13:03, schrieb Thomas Keller: Am 31.05.2010 01:01, schrieb Thomas Keller: 200 diff_patch_drop FAIL (line 29) Apparently the BSD version of patch does not drop files - can we make a guard for that in the test? I've found the man page for patch on openBSD (http://www.openbsd.org/cgi-bin/man.cgi?query=patch) and it contains no mention of special handling of the source / target path /dev/null. Also, the explanation of the -E (--remove-empty-files) option tells nothing about the automatic removal of empty files, so I guess openBSD's patch always needs an explicit -E given to do what patch does automatically on other platforms. Even if it would do what it should, if the environment variable POSIXLY_CORRECT is found, it acts as if it would be argumented with --posix, which makes it leave empty files alone again. So, what should we do here? The addition of -E for all other unices would mean that we'd tamper the test. We check there whether the diff input is so well-formed that a normal unix patch would act correctly and remove the file if it is empty. If we would always give -E, patch would remove it every time (as long as it is empty), even if it does not have the correct header (change a test diff to use /dev/nul instead of /dev/nul, f.e., to see the effect - the file is no longer removed on compliant systems). Do we care enough to skip this test altogether on freebsd and openbsd or should we just parametricize patch with -E only on these platforms? 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] Time for a release
On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote: So, what should we do here? The addition of -E for all other unices would mean that we'd tamper the test. I distinctly remember having to add -E on SunOS, and I would not be at all surprised if, well, anyone else who doesn't use GNU patch had the same behavior. Therefore I think we should unconditionally add -E. (change a test diff to use /dev/nul instead of /dev/nul, f.e., to see the effect - the file is no longer removed on compliant systems). I assume you meant /dev/nul instead of /dev/null there? By the way, standard English is e.g. not f.e. It expands to exempli gratia. Yes, that's Latin. I blame the French. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 31.05.2010 01:01, schrieb Thomas Keller: The buildbots look slightly worse: 1) The Debian testing one seems to have update problems from time to time and complains about no rule to make the target `win32/monotone.iss' for `distdir'. Zbigniew, could you please have a look? Fixed in the meantime, thanks Zbigniew! 2) The openBSD one currently fails 5 tests: 101 automate_show_conflicts_defaults FAIL (line 76) The error there is mtn: misuse: branch 'ca.wethonda.atlas.etc' has only 1 head; must be at least 2 for conflicts I think I've noted this before - the bot seems to have a shared database with other things in them and should be fixed. Jack Cummings are you still around? 118 branch_leaves_sync_bug FAIL (line 47) Should be fixed in 06a9ca6ce12f73634c505f826c8363f3bf3033d0. 200 diff_patch_drop FAIL (line 29) Apparently the BSD version of patch does not drop files - can we make a guard for that in the test? 288 log_--diffs unexpected success Fixed in the meantime, thanks Derek! 206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52) 301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22) Both tests fail with restriction includes unknown path on foo2 / foo1. This is still an open issue. 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] Time for a release
On Thu, 03 Jun 2010 13:03:55 +0200 Thomas Keller wrote: 2) The openBSD one currently fails 5 tests: 200 diff_patch_drop FAIL (line 29) Apparently the BSD version of patch does not drop files - can we make a guard for that in the test? OpenBSD (4.7-current at least) should drop files if -E parameter is used: -E, --remove-empty-files Causes patch to remove output files that are empty after the patches have been applied. This option is useful when applying patches that create or remove files. GNU patch (tested on Debian) should support -E also. -- Tero Koskinen tero.koski...@iki.fi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 31.05.10 01:01, schrieb Thomas Keller: I'll give translators and testers a bigger time frame for this release (at least two weeks from now), because I'd like to switch the release numbering and make 0.48 become 1.0.0 as discussed in the other thread. So if you have some time and like to polish one or two things in the UI, then you're very welcome :) I've just talked with Thomas Moschny on IRC and I listened again to his and other people's concerns about switching too fast to 1.0. I think the concerns are reasonable, so we've discussed this issue and concluded the following: * The next version of monotone will be named 0.99 and will be the last version before the final 1.0.0 is out * The time frame between 0.99 and 1.0.0 won't be longer than a couple of weeks (probably not more than four) - enough to get feedback, flesh out remaining issues as well as polishing strings, documentation (wiki?) and other things which may arise. * NO new features should be merged within this time frame. To not block other people's work too much, I'm proposing we create a new release branch for the work after 0.99 - named nvm.releases.1_0_0. This could later be used for bug fixes on the final 1.0.0 release as well and the normal development would continue to happen in nvm. * Naturally every feature which is worked on nvm would get into the next minor version (after 1.0.0 this would be 1.1.0) which we would branch off from nvm if we decide that its stable enough. Here are again the (adapted) rules when we'll raise the major / minor / patch level in the future: 1) if a release only consists of bug fixes, documentation or i18n fixes, raise the patch level 2) if a release has new features (minor and major), which do not break network or automate compatibility (i.e. no raise in the major automate version number), but which might require a database upgrade or the regeneration of the cache, raise the minor level 3) if a major flag day introduces network incompatibility, or the automate interface has been changed in an incompatible way, or anything worse happened, raise the major level While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like to give my release manager hat to somebody else afterwards, so I can concentrate on other things a bit more. I'm not out of the world, so whoever wants to take the job can of course count on my help. Doing releases does not involve much - the process is fairly good documented. Perhaps the most important skills are a bit of a passion for the software and some accuracy :) So, who's up for the job? 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] Time for a release
On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller m...@thomaskeller.biz wrote: I've just talked with Thomas Moschny on IRC and I listened again to his and other people's concerns about switching too fast to 1.0. I think the concerns are reasonable, so we've discussed this issue and concluded the following: * The next version of monotone will be named 0.99 and will be the last version before the final 1.0.0 is out I agree with the general concern that we've had a few branches land lately. I wouldn't be surprised in the least to hear some screaming when people start using the new changelog editor functionality for example. Also, restrictions have been changed a bit, diff has also changed slightly, etc. Hopefully these changes are all good and generally liked, but the idea of changing a bunch of behaviour and then releasing 1.0 shortly afterwards seems a bit questionable. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller m...@thomaskeller.biz wrote: 206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52) 301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22) Both tests fail with restriction includes unknown path on foo2 / foo1. This is still an open issue. I'd like to see the detailed tester.log files for these but I have no idea how to get them. If someone can point me in the right direction I'll take a look. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi, 2010/5/31 Zbigniew Zagórski z.zagor...@gmail.com: 2010/5/31 Thomas Keller m...@thomaskeller.biz: 1) The Debian testing one seems to have update problems from time to time and complains about no rule to make the target `win32/monotone.iss' for `distdir'. Zbigniew, could you please have a look? My fault - thanks for poiting this out (I should have grep for users of this file before making it generated). monotone.iss is explicitly specified in EXTRA_DIST. I will correct it this evening. Fixed. Sorry for problem! -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi! 2010/5/31 Thomas Keller m...@thomaskeller.biz: Hi all! Its release time, again :), and I would like you to look over the translations and build bots and get them in a good and usable state. I am wondering if we can safely use gcc-4.5.0 to build Windows native version of monotone. Current status is that almost all (lua locale issue again) tests are passing. For those interested in testing stability of new build chain, there is updated setup of 0.47 in downloads. http://monotone.ca/downloads/0.47/monotone-0.47-gcc450-setup.exe I just think that it might be good to check if new compilation environment doesn't bring any surprises. 1) The Debian testing one seems to have update problems from time to time and complains about no rule to make the target `win32/monotone.iss' for `distdir'. Zbigniew, could you please have a look? My fault - thanks for poiting this out (I should have grep for users of this file before making it generated). monotone.iss is explicitly specified in EXTRA_DIST. I will correct it this evening. -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Sun, May 30, 2010 at 5:01 PM, Thomas Keller m...@thomaskeller.biz wrote: 4) For me on Mac OS X all tests run through, even one unexpectedly (log_--diff) - Derek, should this test be un-xfailed? Indeed it should. I'll clean that up tonight. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
Am 18.05.2010 07:03, schrieb Derek Scherger: On Mon, May 17, 2010 at 2:33 AM, Thomas Keller m...@thomaskeller.biz wrote: \2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. I had a quick look over your changes and they seem fairly reasonable. A few minor things: We seem to be using lots of redundant std:: prefixes in various .cc files (not just in your changes) where we also have using std::foo declarations to avoid needing the std:: prefixes throughout the implementation. Do people have a general preference for explicit prefixes? Personally I much prefer a using declaration and less cluttered sources, iterators are already bad enough, sprinkling them with std:: makes them worse! ;) I'm almost everytime use the std:: prefixes to make it explicit, but you are right it makes everything even more hard to read. I'll change that accordingly. Some of your changelog comments use very long lines and are somewhat hard to read without a tool that does automatic, but careful, wrapping (viewing these in emacs diff-mode is not particularly pleasant). Can you try and wrap these at some reasonable length please? Of course, totally my fault. I'm too used to this style for guitone and guitone properly wraps lines... :) On the other hand one could see that as a feature request for the log output - wrap long lines with an \ at the end if f.e. some --wrap option is given. Based on all the shenanigans with .mtn extensions it seems like maybe the path handling code could use a more formal concept of extension. Hrm... I'd see this a bit out of scope for this branch, but if you're in the mood, go on, I won't hold you off :) A shared_ptr for the lazy_rng would probably be better than a raw pointer. I will change that - it was a raw pointer before and I haven't thought about changing that. We should probably have a :memory: constant somewhere, rather than multiple string instances. Good catch, will change that as well. I don't think you want to set the foo_given flags when reading options from the options file do you? Isn't the point of these to know whether the user specified such an option on the command line? In this context it actually means if the particular stanza is written out at all in _MTN/options, i.e. not empty. This may not make sense much for the current options there, but I thought it is stringent to how the command line options parser works. Since we use a options structure to fill in the options from _MTN/options there, I aimed for 100% compatibility with the command line parser. Thanks for the review! 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] time for a release?
Am 17.05.2010 08:32, schrieb Stephen Leake: Timothy has fixed the branch_leaves cache bug, and merged the change-log editor improvements and added --update/--no-update to main. Several other bug fixes have been done. And all tests are currently passing (at least on Debian). So I think it's time for a release? Yes, it is time, but I'd like to wait a little longer, for a couple of reasons: 1) I want to have all finished branches from our bugfest merged in first (I'm not sure, but I think at least Richard's is missing) 2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. 3) I want to have a time window between the last feature merge and the release of at least one or two weeks, for two reasons: have more people test the changes and give the translators a chance to pick up the new strings. So from the current point of view a release should be realistic around June 1st or shortly after. 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] time for a release?
Thomas Keller m...@thomaskeller.biz writes: Am 17.05.2010 08:32, schrieb Stephen Leake: Timothy has fixed the branch_leaves cache bug, and merged the change-log editor improvements and added --update/--no-update to main. Several other bug fixes have been done. And all tests are currently passing (at least on Debian). So I think it's time for a release? Yes, it is time, but I'd like to wait a little longer, for a couple of reasons: 1) I want to have all finished branches from our bugfest merged in first (I'm not sure, but I think at least Richard's is missing) Ok. 2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. Yes, that would be good. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. I'll try to look at it. 3) I want to have a time window between the last feature merge and the release of at least one or two weeks, for two reasons: have more people test the changes and give the translators a chance to pick up the new strings. So from the current point of view a release should be realistic around June 1st or shortly after. Sounds good. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
Am 17.05.2010 10:33, schrieb Thomas Keller: Am 17.05.2010 08:32, schrieb Stephen Leake: Timothy has fixed the branch_leaves cache bug, and merged the change-log editor improvements and added --update/--no-update to main. Several other bug fixes have been done. And all tests are currently passing (at least on Debian). So I think it's time for a release? Yes, it is time, but I'd like to wait a little longer, for a couple of reasons: 1) I want to have all finished branches from our bugfest merged in first (I'm not sure, but I think at least Richard's is missing) 2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. 3) I want to have a time window between the last feature merge and the release of at least one or two weeks, for two reasons: have more people test the changes and give the translators a chance to pick up the new strings. On a related note, apparently some of the build bots fail - at least the Fedora one http://monotone.thomaskeller.biz/autobuild/index.php?log=Fedora_12/i586/monotone-fedora and the openBSD one http://monotone.ca/buildbot/x86-openbsd/builds/803/step-test/0 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] time for a release?
On Mon, May 17, 2010 at 2:33 AM, Thomas Keller m...@thomaskeller.biz wrote: \2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. I had a quick look over your changes and they seem fairly reasonable. A few minor things: We seem to be using lots of redundant std:: prefixes in various .cc files (not just in your changes) where we also have using std::foo declarations to avoid needing the std:: prefixes throughout the implementation. Do people have a general preference for explicit prefixes? Personally I much prefer a using declaration and less cluttered sources, iterators are already bad enough, sprinkling them with std:: makes them worse! ;) Some of your changelog comments use very long lines and are somewhat hard to read without a tool that does automatic, but careful, wrapping (viewing these in emacs diff-mode is not particularly pleasant). Can you try and wrap these at some reasonable length please? Based on all the shenanigans with .mtn extensions it seems like maybe the path handling code could use a more formal concept of extension. A shared_ptr for the lazy_rng would probably be better than a raw pointer. We should probably have a :memory: constant somewhere, rather than multiple string instances. I don't think you want to set the foo_given flags when reading options from the options file do you? Isn't the point of these to know whether the user specified such an option on the command line? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zbigniew Zagórski wrote: Hi! 2010/3/8 Timothy Brownawell tbrow...@prjek.net mailto:tbrow...@prjek.net empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I've faced this problem last time and result is that the only known tool - depends.exe [1] has also CLI interface. It's a little awkward so i've made simple wrapper [2] that makes readable ldd greppable output. [1] http://www.dependencywalker.com/ [2] http://pastebin.com/wxreDxFu Thanks! The empty_enviroment test will use this now for windows/mingw, but currently not cygwin (just because I don't have Cygwin set up to test it with). This apparently is included with Visual Studio, and should work automatically in that case without needing to add things to %PATH%. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Timothy Brownawell tbrow...@prjek.net writes: Stephen Leake wrote: The following tests are failing on Win32: 9 (normal)_netsync_on_partially_unrelated_revisions FAIL (error creating test directory) 0:00, 0:00 on CPU 210 empty_environment FAIL (line 45) 69:34 341 multiple_version_committing FAIL (line 25) 0:01 423 restricted_commit_with_inodeprintsFAIL (error creating test directory) 0:00, 0:00 on CPU 459 schema_migration FAIL (line 106) 0:12 empty_environment has been failing for a while; the others are new. I have not looked at them in detail yet. All tests pass for me on Win32/MinGW. empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I'll just skip this one, in light of my other problems. I'd guess the others are probably issues with races and Windows' file locking... Yes. Rerunning each individually lets them succeed. Windows is _such_ a wonderfully stable platform :(. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller m...@thomaskeller.biz writes:
I'm preparing the next monotone currently, which will probably happen
Sunday evening. Please check if your translations are up-to-date (there
hasn't happened much since 0.46 in this area though), if the current
head builds on your platform and if all of the tests (beside the usual
suspects which failed earlier as well) run through.
As of
0422a7ef26ec104049ea29c1bc6e55262aded5e2 de...@echologic.com 2010-03-07T06:17:34
all tests pass for me on Debian.
On Win32, I fixed the race condition that was preventing the test
suite from running. More precisely, I found the cause and added a
work-around; not a true fix. The problem was in win32/tester-plaf.cc
run_tests_in_children. Near the end, it does:
if (child == -1)
status = 122;
else
process_wait(child, status);
DWORD end_millis = GetTickCount();
if (cleanup(t, status, (end_millis - start_millis) / 1000, -1))
do_remove_recursive(testdir);
Apparently sometimes process_wait can return before releasing the lock
on testdir, so do_remove_recursive fails. I added a wait in this case:
if (cleanup(t, status, (end_millis - start_millis) / 1000, -1))
try
{
do_remove_recursive(testdir);
}
catch (...)
{
// process_wait sometimes returns before releasing the lock on
// the directory that we tried to remove. So wait a little
// longer and try again.
Sleep (1000);// milliseconds
do_remove_recursive(testdir);
}
That lets the tests run to completion on my machine. For the wait time
400 was too short, 1000 worked; I stopped bisecting there, since it
doesn't actually hit that case often. Committed in
838009162c0fd6b6248d6a83f75771933e4a8b15
The following tests are failing on Win32:
9 (normal)_netsync_on_partially_unrelated_revisions FAIL (error creating test
directory) 0:00, 0:00 on CPU
210 empty_environment FAIL (line 45) 69:34
341 multiple_version_committing FAIL (line 25) 0:01
423 restricted_commit_with_inodeprintsFAIL (error creating test
directory) 0:00, 0:00 on CPU
459 schema_migration FAIL (line 106) 0:12
empty_environment has been failing for a while; the others are new. I
have not looked at them in detail yet.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi! 2010/3/8 Timothy Brownawell tbrow...@prjek.net empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I've faced this problem last time and result is that the only known tool - depends.exe [1] has also CLI interface. It's a little awkward so i've made simple wrapper [2] that makes readable ldd greppable output. [1] http://www.dependencywalker.com/ [2] http://pastebin.com/wxreDxFu Regards! -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
this is a small program I use to copy a program(or library) and all of its related libraries which are not in %SYSTEMROOT% to a destination... http://sack.svn.sourceforge.net/viewvc/sack/src/utils/pcopy/ Unfortunatly it's got a few dependancies on other code in SACK - like the routine that scans a directory for all files in it... On Mon, Mar 8, 2010 at 6:11 AM, Timothy Brownawell tbrow...@prjek.net wrote: Stephen Leake wrote: The following tests are failing on Win32: 9 (normal)_netsync_on_partially_unrelated_revisions FAIL (error creating test directory) 0:00, 0:00 on CPU 210 empty_environment FAIL (line 45) 69:34 341 multiple_version_committing FAIL (line 25) 0:01 423 restricted_commit_with_inodeprints FAIL (error creating test directory) 0:00, 0:00 on CPU 459 schema_migration FAIL (line 106) 0:12 empty_environment has been failing for a while; the others are new. I have not looked at them in detail yet. All tests pass for me on Win32/MinGW. empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I'd guess the others are probably issues with races and Windows' file locking... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-i18n] Re: [Monotone-devel] Time for a release
Remind me of how you do it (or send me whatever script you use) and I'll take over that part, if you want. Cheers, Richard In message eb97335b1003041115h13980990s12d0cec0b40e...@mail.gmail.com on Thu, 4 Mar 2010 11:15:46 -0800, Zack Weinberg za...@panix.com said: zackw This seems like a good time to mention that I really don't want to be zackw responsible for Debian packaging anymore. zackw zackw Packaging is not hard, but can be very time-consuming and tedious. I zackw never got around to doing 0.46. There are a few bugs in their tracker zackw that should definitely be fixed. zackw zackw zw zackw zackw On Thu, Mar 4, 2010 at 10:07 AM, Thomas Keller m...@thomaskeller.biz wrote: zackw zackw Hi all! zackw zackw I'm preparing the next monotone currently, which will probably happen zackw Sunday evening. Please check if your translations are up-to-date (there zackw hasn't happened much since 0.46 in this area though), if the current zackw head builds on your platform and if all of the tests (beside the usual zackw suspects which failed earlier as well) run through. zackw zackw If you have anything of which you think should stop the release process, zackw then please let me know. zackw zackw Thanks in advance, zackw Thomas. zackw zackw -- zackw GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz zackw Please note that according to the EU law on data retention, information zackw on every electronic information exchange might be retained for a period zackw of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en zackw zackw zackw ___ zackw Monotone-devel mailing list zackw Monotone-devel@nongnu.org zackw http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 04.03.10 19:07, schrieb Thomas Keller: Hi all! I'm preparing the next monotone currently, which will probably happen Sunday evening. Please check if your translations are up-to-date (there hasn't happened much since 0.46 in this area though), if the current head builds on your platform and if all of the tests (beside the usual suspects which failed earlier as well) run through. Currently three tests are failing for me, namely diffing_a_file_within_revision_outside_a_workspace (line 52) logging_a_file_within_revision_outside_a_workspace (line 22) - both have similar issues, apparently a non-existing old path can not be used in a restriction outside of a workspace, but I haven't looked in detail here - as well as automate_show_conflicts_defaults (line 76) this fails with mtn: misuse: branch 'test' has only 1 head; must be at least 2 for conflicts I'll try to have a look at these tomorrow or Sunday, but if somebody wants to pick them up as well, be my guest. 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] Time for a release
This seems like a good time to mention that I really don't want to be responsible for Debian packaging anymore. Packaging is not hard, but can be very time-consuming and tedious. I never got around to doing 0.46. There are a few bugs in their tracker that should definitely be fixed. zw On Thu, Mar 4, 2010 at 10:07 AM, Thomas Keller m...@thomaskeller.biz wrote: Hi all! I'm preparing the next monotone currently, which will probably happen Sunday evening. Please check if your translations are up-to-date (there hasn't happened much since 0.46 in this area though), if the current head builds on your platform and if all of the tests (beside the usual suspects which failed earlier as well) run through. If you have anything of which you think should stop the release process, then please let me know. Thanks in advance, 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 06.01.2010 14:20, schrieb Thomas Keller: Hey there! As I have announced earlier on IRC I plan to release monotone 0.46 in a few weeks, before February to be more precise. I'd like to get my nvm.automate-netsync branch in a mergable state until then (docs and tests are still missing) and I think we then have quite a sounding release with enough features and fixes. I'd like you to already check the latest head and report build problems since we do not have many functional build bots right now. (It would be even better to fix the bots, but apparently all the people who still manage one have disappeared since I've made this call for 0.45...) Also, translators, please already start and translate the strings, so we're safe in this area as well. The nvm.automate-netsync branch will not introduce many new ones, so translating these before 0.46 is released shouldn't then take so long. Is everybody ok with releasing 0.46 this weekend? I've only seen i18n updates from Richard so far, can the other people keep up the pace or should we delay the release another week? Also, there have been no improvement on the build front, despite that I've collected a couple of personal yes it works notifications. Somebody contacted me privately that he wanted to setup a Gentoo buildbot. I've pointed him to the wiki which explains the setup, but haven't heard anything from him since that. We also got recently a notification that 0.45 (and likely also 0.46) won't compile on gcc-4.5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565083 I don't know the release schedule of gcc, but maybe we could fix this one specific issue before 0.46 is out, because I doubt we have another release out in a month or so, so 0.46 will be around for a while. 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] Time for a release
Am 11.01.2010 13:28, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: As I have announced earlier on IRC I plan to release monotone 0.46 in a few weeks, before February to be more precise. I'd like to get my nvm.automate-netsync branch in a mergable state until then (docs and tests are still missing) and I think we then have quite a sounding release with enough features and fixes. I'd like you to already check the latest head and report build problems since we do not have many functional build bots right now. (It would be even better to fix the bots, but apparently all the people who still manage one have disappeared since I've made this call for 0.45...) I just pushed a rev 85c502bfa72dded523b9fda446db9e6847a0170a that fixes an uninitialized pointer bug in the new out_of_band_handler stuff. Thanks for that! All tests pass on Debian testing. All but three pass on Windows (these three have been broken for the last couple releases as well): 89 automate_lua FAIL (line 56) 0:00 appears to be a bug in the windows implementation of lua?! 159 date_formatting FAIL (line 26) 0:00 %T doesn't work 208 empty_environment FAIL (line 45) 69:34 can't find dll because PATH is changed As before, I don't think these are worth holding the release for. One of these they may make it to the top of my list. If all of them failed for 0.45 as well, there is surely nothing there holding off a release. Still, it would be cool to get them sorted out in mid-term. Thanks again, 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] Time for a release
Am Thu, 14 Jan 2010 09:43:18 +0100 schrieb Thomas Keller m...@thomaskeller.biz: We also got recently a notification that 0.45 (and likely also 0.46) won't compile on gcc-4.5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565083 I don't know the release schedule of gcc, but maybe we could fix this one specific issue before 0.46 is out, because I doubt we have another release out in a month or so, so 0.46 will be around for a while. As far as Fedora is concerned, gcc 4.5 will not be in F13, and F14 could be released in November, so there's some time left. Anyway, the fix was easy, it was a missing #include roster.hh in selectors.cc, committed in 743110f6dc3d8b3dd2b975eb4dec13f1e2e47c09. Btw, while checking this in a debian chroot, I saw the netsync_largish_file test failing: [...] mtn: peer localhost:59751 IO terminated connection in working state (error) mtn: error: I/O failure while talking to peer localhost:59751, disconnecting [...] mtn: peer 127.0.0.1:41314 IO failed in working state (error) mtn: operation canceled: Terminated [...] Is anyone else able to reproduce this, or has any clue what's going on there? -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller m...@thomaskeller.biz writes: As I have announced earlier on IRC I plan to release monotone 0.46 in a few weeks, before February to be more precise. I'd like to get my nvm.automate-netsync branch in a mergable state until then (docs and tests are still missing) and I think we then have quite a sounding release with enough features and fixes. I'd like you to already check the latest head and report build problems since we do not have many functional build bots right now. (It would be even better to fix the bots, but apparently all the people who still manage one have disappeared since I've made this call for 0.45...) I just pushed a rev 85c502bfa72dded523b9fda446db9e6847a0170a that fixes an uninitialized pointer bug in the new out_of_band_handler stuff. All tests pass on Debian testing. All but three pass on Windows (these three have been broken for the last couple releases as well): 89 automate_lua FAIL (line 56) 0:00 appears to be a bug in the windows implementation of lua?! 159 date_formatting FAIL (line 26) 0:00 %T doesn't work 208 empty_environment FAIL (line 45) 69:34 can't find dll because PATH is changed As before, I don't think these are worth holding the release for. One of these they may make it to the top of my list. I'm also still getting the intermittent failure to delete the test directory due to a race condition, so I have to rerun some tests by hand. That's more likely to make it to the top of my list :). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
I'd like to draw people's attention to Debian bug 559893: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559893 This is, at root, a problem with contrib/get_passphrase_from_file.lua, which was never updated for the keys-by-hash changes. I doubt I will have time to look at this before your proposed release [my time to work on monotone is extremely limited these days] but it would be really nice if it could get fixed. It doesn't appear to me that the hook documentation was properly updated for keys-by-hash either. zw On Wed, Jan 6, 2010 at 5:20 AM, Thomas Keller m...@thomaskeller.biz wrote: Hey there! As I have announced earlier on IRC I plan to release monotone 0.46 in a few weeks, before February to be more precise. I'd like to get my nvm.automate-netsync branch in a mergable state until then (docs and tests are still missing) and I think we then have quite a sounding release with enough features and fixes. I'd like you to already check the latest head and report build problems since we do not have many functional build bots right now. (It would be even better to fix the bots, but apparently all the people who still manage one have disappeared since I've made this call for 0.45...) Also, translators, please already start and translate the strings, so we're safe in this area as well. The nvm.automate-netsync branch will not introduce many new ones, so translating these before 0.46 is released shouldn't then take so long. Thanks for your work! 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
*ahem* I have ficed the problem in 5a498d0437f0da74ae49380ef561b948db1a056a The next upgrade will contain the change. Now, all that's needed is for the Debian installer to update /etc/monotone/hooks.lua properly. In message eb97335b1001061146s3a5c67fdk495a0e0797b86...@mail.gmail.com on Wed, 6 Jan 2010 11:46:49 -0800, Zack Weinberg za...@panix.com said: zackw I'd like to draw people's attention to Debian bug 559893: zackw http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559893 zackw zackw This is, at root, a problem with contrib/get_passphrase_from_file.lua, zackw which was never updated for the keys-by-hash changes. I doubt I will zackw have time to look at this before your proposed release [my time to zackw work on monotone is extremely limited these days] but it would be zackw really nice if it could get fixed. zackw zackw It doesn't appear to me that the hook documentation was properly zackw updated for keys-by-hash either. zackw zackw zw zackw zackw On Wed, Jan 6, 2010 at 5:20 AM, Thomas Keller m...@thomaskeller.biz wrote: zackw zackw Hey there! zackw zackw As I have announced earlier on IRC I plan to release monotone 0.46 in a zackw few weeks, before February to be more precise. I'd like to get my zackw nvm.automate-netsync branch in a mergable state until then (docs and zackw tests are still missing) and I think we then have quite a sounding zackw release with enough features and fixes. zackw zackw I'd like you to already check the latest head and report build problems zackw since we do not have many functional build bots right now. (It would be zackw even better to fix the bots, but apparently all the people who still zackw manage one have disappeared since I've made this call for 0.45...) zackw zackw Also, translators, please already start and translate the strings, so zackw we're safe in this area as well. The nvm.automate-netsync branch will zackw not introduce many new ones, so translating these before 0.46 is zackw released shouldn't then take so long. zackw zackw Thanks for your work! zackw zackw Thomas. zackw zackw -- zackw GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz zackw Please note that according to the EU law on data retention, information zackw on every electronic information exchange might be retained for a period zackw of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en zackw zackw zackw zackw ___ zackw Monotone-devel mailing list zackw Monotone-devel@nongnu.org zackw http://lists.nongnu.org/mailman/listinfo/monotone-devel zackw zackw zackw zackw zackw ___ zackw Monotone-devel mailing list zackw Monotone-devel@nongnu.org zackw http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg wrote: On Sat, Sep 12, 2009 at 12:45 AM, Lapo Luchini l...@lapo.it wrote: % make monotone.pot make: *** No rule to make target `monotone.pot'. Stop. This has been changed to $ make $LANG.po-update in the past. Both targets exist and do different things. Ah ok. Then I'll continue to use make monotone.pot (using poEdit it can import a .pot file itself, and also has additional knowledge like showing new strings in a different color) configure failed to find at least one of the msgfmt, msgmerge, and xgettext programs. It won't enable those rules unless you have all three. Gotcha. I was pretty convinced I had 'em already... but no, I was wrong. -- Lapo Luchini - http://lapo.it/ “C is quirky, flawed, and an enormous success.” (Dennis M. Ritchie) 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] Time for a release
Thomas Keller m...@thomaskeller.biz writes: We also currently have no (active) buildbot for win32 Test results on MinGW for b13449292bbdcadf9f1e6515faaeee5fffc1ce7d - all pass except: 89 automate_lua FAIL (line 56) 0:00 This appears to be a bug in the windows implementation of lua?! This line works: echo(0, nil, 'foo') while this doesn't: echo(0, nil, 'foo') I can't imagine why! 156 date_formatting FAIL (line 26) 0:00 %T doesn't work 203 empty_environment FAIL (line 40) 0:02 apparently mingw 'env' is broken I don't think any of these are show stoppers. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
FYI, since the Debian translation teams have been very prompt about translating the extra messages used by the monotone-server package (this provides init.d scripts and so on for running a monotone server), I've asked them for help with the more out-of-date translations -- es, fr, ja, pt_BR. I hope this doesn't step on anyone's toes. I doubt they will be able to do anything by Friday, regardless. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg schrieb: FYI, since the Debian translation teams have been very prompt about translating the extra messages used by the monotone-server package (this provides init.d scripts and so on for running a monotone server), I've asked them for help with the more out-of-date translations -- es, fr, ja, pt_BR. I hope this doesn't step on anyone's toes. I doubt they will be able to do anything by Friday, regardless. Yes, I figured something like that because I got recently contacted privately by somebody who offered help for the German translation. This one is now complete, but nevertheless more (up-to-date) translations would be very cool, even if we get them only after 0.45 is out. Thanks for your effort :) 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] Time for a release
Thomas Keller m...@thomaskeller.biz writes: 2) The buildbots i386-win32-mingw, This was mine. The machine physically died, and I don't have the resources (or time) to replace it yet. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg schrieb: On Wed, Mar 11, 2009 at 6:29 PM, Thomas Keller m...@thomaskeller.biz wrote: As I've already announced on IRC I want to do a release in the next couple of days, a possible date could be Sunday, 2009-03-15, but depending on the feedback what people like to get done before 0.43 hits the world, I'll not insist on this date. The Debian packaging scripts need a major overhaul for the .stripped work. I will not have time for this until a week from Friday (that's the 20th). This does not *have* to hold the release but I would prefer that it did, because it is likely that I will find changes needing to be made in the code proper, or at least the documentation. Ok, I'm fine with that. Then I schedule the release for 22nd of March. 0) I've came across a couple of older systems where our dependency for prce (7.6, released in January 2008) could not be met. I know 7.6 includes an important buffer overflow fix and I know this probably was backported by some lts distros, but still, from a *functional* point of view, what version of pcre is required? Seems as if the first pcre version we've included was 7.4 in monotone-0.37 (at least this was the most recent one before 0.37 was released). I believe 7.4 is the minimum for functionality, yes. I've lowered our requirement to 7.4. Thanks, 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] Time for a release
In message 86r61012tz@stephe-leake.org on Sat, 14 Mar 2009 12:33:44 -0400, Stephen Leake stephen_le...@stephe-leake.org said: stephen_leake Thomas Keller m...@thomaskeller.biz writes: stephen_leake stephen_leake 2) The buildbots i386-win32-mingw, stephen_leake stephen_leake This was mine. The machine physically died, and I don't have the stephen_leake resources (or time) to replace it yet. I've temporarly removed it. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Derek Scherger schrieb: On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller m...@thomaskeller.biz wrote: 6) Derek, whats up with nvm.experiment.binary-roster-deltas, This was purely an experiment. I was hoping that it would speed up roster loading but it didn't make any measurable difference so I think it's a dead end. The binary format was possibly a bit nicer than the associated basic_io format that it replaced in terms of the printing and parsing code. If we ever do move away from basic_io to length prefixed binary data this could be an example of one approach. Ok, then this is stalled. Should we suspend these and similar branches? nvm.changelog-editor and I'm still hoping to do something with this, but I'm not in any rush and I don't think this should hold up the release. Possibly the thing to do is to move more of this into lua hooks so it is configurable. I would very much like to unify the output from 'mtn status' and 'mtn log' so that we have one pretty printed form of revisions used by both commands. If this format can be worked into the commit command as well then all the better. No rush on this one, either. I just have the slight feeling that ambitious (working) experiments in the past tend to die a slow death because they're forgotten after some time. I speak for myself here as well, having a lot of unfinished work laying around from 2008 or even 2007... I have wished I had editable branch names during commits on numerous occasions so I would like to get some agreement on this. At least a couple of people have wondered about a lua hook or something to enable/disable this feature which can be done but I'm a bit skeptical on whether this is really necessary or not. I think the main problem here is that it is so hard to recover from failures. A possible solution to this dilemma w/o any additional lua foo could also be: * print all issued certs directly after a commit * have a simple mtn dropcert revid certname command which can undo a failure If this is in place I'd even vote for expanding the functionality to allow multiple new certs, just like it is possible to add email headers. I.e. why not adding multiple author certs on a revision which origins from a patch by adding new author: lines? To unify output from status and log we need to settle on one of the two different output formats. Status currently prints one line per path, with a single word prefix indicating what changed while log currently prints a more abbreviated summary which is very much influenced by the internal structure of a cset. I prefer the output from status over that of log so that's the direction I would move in if there are no objections. It will be a few weeks before I get back to this line of changes though. I agree that this is wanted, but I could actually see this happen sometime later, this is not directly related to the changelog edit functionality. nvm.experiment.log-options? Should any of those This one is dead. Without much effort, Dan convinced me that selectors were a better approach than options and having done that I very much agree. [...] Then this branch should probably be suspended. The one thing I would like to get sorted out before a release is the issue described here: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/16118 Which is about setting/clearing execute bits based on mtn:execute. In a nutshell, the idea is that if mtn:execute is set to true we set the execute bits, if it's set to false we clear them, otherwise we leave them alone. This seems reasonably sensible, but means that if you update from a rev with mtn:execute set to true on some file to some earlier rev where that file had no mtn:execute attribute the execute bits will be left on rather than cleared. Do you see that as a blocker for 0.43? While the attribute handling is still not perfect, it already got a lot better, no? 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] Time for a release
On Thu, Mar 12, 2009 at 10:11:13AM +0100, Thomas Keller wrote: This one is dead. Without much effort, Dan convinced me that selectors were a better approach than options and having done that I very much agree. [...] Yeah, I like the outcome here a lot. Then this branch should probably be suspended. I'd like to also suggest and propose an additional convention, when using suspend certs - that is to also add a comment cert describing the reason for the suspension. Which is about setting/clearing execute bits based on mtn:execute. In a nutshell, the idea is that if mtn:execute is set to true we set the execute bits, if it's set to false we clear them, otherwise we leave them alone. This seems reasonably sensible, but means that if you update from a rev with mtn:execute set to true on some file to some earlier rev where that file had no mtn:execute attribute the execute bits will be left on rather than cleared. Do you see that as a blocker for 0.43? While the attribute handling is still not perfect, it already got a lot better, no? Is this also the case for a forward update - ie, from a rev with an explicit setting to a rev where the attr has been dropped? If so, I'd say it could be worth more consideration - otherwise it's rare enough that it can be addressed with documentation in the meantime. I'm not convinced this is the wrong behaviour in either case (dropping the attr amounts to a don't care setting), but some thought about least surprise for user expectations is needed. The counter-argument is that update should produce the same result as checkout, plus local changes, and checkout defaults to no-exec. So.. perhaps diff or status should show the x-bit set somehow as a workspace change carried across from the update? Could be useful in general to find files that have mismatched attrs -- Dan. pgpyrLN8ggSaG.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
2009/3/12 Thomas Keller m...@thomaskeller.biz Derek Scherger schrieb: On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller m...@thomaskeller.biz wrote: 6) Derek, whats up with nvm.experiment.binary-roster-deltas, Ok, then this is stalled. Should we suspend these and similar branches? This one should probably be suspended, yes. nvm.changelog-editor and No rush on this one, either. I just have the slight feeling that ambitious (working) experiments in the past tend to die a slow death because they're forgotten after some time. I speak for myself here as well, having a lot of unfinished work laying around from 2008 or even 2007... Agreed. It's pretty high on my list of things to look at so with any luck I'll get back to it in the not too distant future. I have wished I had editable branch names during commits on numerous occasions so I would like to get some agreement on this. At least a couple of people have wondered about a lua hook or something to enable/disable this feature which can be done but I'm a bit skeptical on whether this is really necessary or not. I think the main problem here is that it is so hard to recover from failures. A possible solution to this dilemma w/o any additional lua foo could also be: * print all issued certs directly after a commit ... in the same format as the revision headers printed by status and log. ;) * have a simple mtn dropcert revid certname command which can undo a failure Yeah, this would essentially allow for amending certs (ok, replacing them) on revisions you have committed but not pushed a little more conveniently. My problem is that I never see the problem until *after* I've pushed something and see spelling errors in the irclogger messages. If this is in place I'd even vote for expanding the functionality to allow multiple new certs, just like it is possible to add email headers. I.e. why not adding multiple author certs on a revision which origins from a patch by adding new author: lines? This would also be easy enough to do. Apparently there are lots of strong feelings on this as well, with regard to things like the mutt email client and its ability to edit headers or some such. I'm not sure I see what the fuss is all about though, if you want to add headers and can't then you're stuck, if you don't want to add headers but you can and choose not to then all is well. To unify output from status and log we need to settle on one of the two different output formats. Status currently prints one line per path, with a single word prefix indicating what changed while log currently prints a more abbreviated summary which is very much influenced by the internal structure of a cset. I prefer the output from status over that of log so that's the direction I would move in if there are no objections. It will be a few weeks before I get back to this line of changes though. I agree that this is wanted, but I could actually see this happen sometime later, this is not directly related to the changelog edit functionality. It's certainly a good idea to get something done, rather than have overly grand scheme's that prevent you from getting anything done. I was thinking along these lines with the first few commits to the changelog-editor branch, in terms of not touching the log output. nvm.experiment.log-options? Should any of those This one is dead. Without much effort, Dan convinced me that selectors were a better approach than options and having done that I very much agree. [...] Then this branch should probably be suspended. Agreed. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
2009/3/12 Daniel Carosone d...@geek.com.au Do you see that as a blocker for 0.43? While the attribute handling is still not perfect, it already got a lot better, no? I'm not sure that it's a blocker but it would be nice to not be changing behaviour like this from release to release if we can help it. Is this also the case for a forward update - ie, from a rev with an explicit setting to a rev where the attr has been dropped? At the moment update will clear the execute bits when moving from a rev with the attr set to one with it dropped or with it set to anything other than true. If we change the hook to only do things when mtn:execute is *set* then update will only clear the execute bits when it's *set* to false. If it was set to any other value or if it was dropped update wouldn't touch the bits. If so, I'd say it could be worth more consideration - otherwise it's rare enough that it can be addressed with documentation in the meantime. I'm not convinced this is the wrong behaviour in either case (dropping the attr amounts to a don't care setting), but some thought about least surprise for user expectations is needed. The counter-argument is that update should produce the same result as checkout, plus local changes, and checkout defaults to no-exec. This is exactly the case where it came up, update didn't produce correct (equivalent to checkout) results in terms of execute bits and checkout can't be used for revisions that don't have branch certs. So there's no good way to get to those revisions with proper execute permission settings. In terms of checkout and update agreeing on execute permissions I think the current behaviour is correct but then revert is the odd man out. If you update to a rev with no mtn:execute attribute on some file, chmod +x that file and then mtn revert that file the execute bits will not be cleared even though both checkout and update would clear them. Another thought here is that revert should use the same editable-tree machinery that checkout and update use to do their work. Then it would get similar results. This turns out to be tricky in a few different ways though. First, update can fail due to workspace conflicts and people probably wouldn't expect revert to fail. The other thing is that reverting a drop is not eactly an addition so things would have to be done carefully in this case to avoid breaking file lifecycles. So.. perhaps diff or status should show the x-bit set somehow as a workspace change carried across from the update? Could be useful in general to find files that have mismatched attrs I had wondered about this as well. The execute bits do feel somewhat like file content and maybe monotone should just track these values similarly and manage the mtn:execute attribute automatically. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller m...@thomaskeller.biz wrote: 6) Derek, whats up with nvm.experiment.binary-roster-deltas, This was purely an experiment. I was hoping that it would speed up roster loading but it didn't make any measurable difference so I think it's a dead end. The binary format was possibly a bit nicer than the associated basic_io format that it replaced in terms of the printing and parsing code. If we ever do move away from basic_io to length prefixed binary data this could be an example of one approach. nvm.changelog-editor and I'm still hoping to do something with this, but I'm not in any rush and I don't think this should hold up the release. Possibly the thing to do is to move more of this into lua hooks so it is configurable. I would very much like to unify the output from 'mtn status' and 'mtn log' so that we have one pretty printed form of revisions used by both commands. If this format can be worked into the commit command as well then all the better. I have wished I had editable branch names during commits on numerous occasions so I would like to get some agreement on this. At least a couple of people have wondered about a lua hook or something to enable/disable this feature which can be done but I'm a bit skeptical on whether this is really necessary or not. To unify output from status and log we need to settle on one of the two different output formats. Status currently prints one line per path, with a single word prefix indicating what changed while log currently prints a more abbreviated summary which is very much influenced by the internal structure of a cset. I prefer the output from status over that of log so that's the direction I would move in if there are no objections. It will be a few weeks before I get back to this line of changes though. nvm.experiment.log-options? Should any of those This one is dead. Without much effort, Dan convinced me that selectors were a better approach than options and having done that I very much agree. The log command now accepts a --revision option to log a specific set of revs. The new u: and m: selectors can be used with this option and allow for logging back to the point of the last update and revisions with changelog messages that match the specified glob respectively. I've been using these quite frequently since adding them and have found them to be quite useful.I added a flush to log around that time as well to at least make it feel like it was moving, but the recent cert loading changes make it go so much faster that this is no longer an issue. I'm really happy with how all of the log stuff has turned out, although I think there is still room for further improvements. The one thing I would like to get sorted out before a release is the issue described here: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/16118 Which is about setting/clearing execute bits based on mtn:execute. In a nutshell, the idea is that if mtn:execute is set to true we set the execute bits, if it's set to false we clear them, otherwise we leave them alone. This seems reasonably sensible, but means that if you update from a rev with mtn:execute set to true on some file to some earlier rev where that file had no mtn:execute attribute the execute bits will be left on rather than cleared. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Timothy Brownawell schrieb:
On Wed, 2008-12-17 at 02:06 +0100, Thomas Keller wrote:
Thomas Keller schrieb:
Its been a while already since 0.41 and I'd like to prepare a new
release - probably the last one for 2008 ;)
[...]
* I've noticed a couple of fixes and changes on IRC which haven't made
it into the NEWS file yet. Would the developers who're now thinking they
could be meant please be so kind and add them? :)
I've updated the NEWS file with anything which I found noteworthy since
0.41. Please re-read and correct possible spelling / grammar / context
errors, in particular the sections about the improvements / bugfixes
from Timothy (since I may not have grasp the real indications / outcome
here).
The hex {en,de}coding and db caching are listed twice, under Bugs
Fixed (second item) and Internal.
Thanks, my fault. This has been corrected.
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] Time for a release
Stephen Leake schrieb: 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). Ok, then I guess we see if / how people use it. It still has to be triggered manually through (explicit_)merge/propagate --resolve-conflicts, right? Or is the conflicts file automatically written to _MTN/conflicts and the user is hinted there? You see, I haven't found time to actually play with it myself - maybe I should. * The buildbots on Win32, Mac OS X and AIX are either dysfunctional or offline. Could somebody (Richard, where are you?) please have a look at them? (Btw... Richard, in case you've missed my email a couple of months ago, please remove the SuSE 9.3 buildbot - this is no longer existing.) I was maintaining the Win32 buildbot; the machine has died. I'm moving to a new house; once I get settled I'll look into replacing it. I can run the monotone test suite on a Win32 machine at work; last I tried it, there were no failures. That would be cool! Is this machine Vista or XP-based? There are some failures in the Cygwin version; I have not tried to fix them recently. Is there anybody else who's using cygwin and who could run the testsuite there? I'll run the testsuite on OSX-10.5/Intel, the PPC/10.4 one seems to succeed. The BSDs then still make some problems, anyone up for looking into them? 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] Time for a release
I wrote: I'll run the testsuite on OSX-10.5/Intel, the PPC/10.4 one seems to succeed. Everything green on OSX 10.5.6 / Intel as well. 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] Time for a release
On Wed, 2008-12-17 at 02:06 +0100, Thomas Keller wrote:
Thomas Keller schrieb:
Its been a while already since 0.41 and I'd like to prepare a new
release - probably the last one for 2008 ;)
[...]
* I've noticed a couple of fixes and changes on IRC which haven't made
it into the NEWS file yet. Would the developers who're now thinking they
could be meant please be so kind and add them? :)
I've updated the NEWS file with anything which I found noteworthy since
0.41. Please re-read and correct possible spelling / grammar / context
errors, in particular the sections about the improvements / bugfixes
from Timothy (since I may not have grasp the real indications / outcome
here).
The hex {en,de}coding and db caching are listed twice, under Bugs
Fixed (second item) and Internal.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller schrieb: Its been a while already since 0.41 and I'd like to prepare a new release - probably the last one for 2008 ;) [...] * I've noticed a couple of fixes and changes on IRC which haven't made it into the NEWS file yet. Would the developers who're now thinking they could be meant please be so kind and add them? :) I've updated the NEWS file with anything which I found noteworthy since 0.41. Please re-read and correct possible spelling / grammar / context errors, in particular the sections about the improvements / bugfixes from Timothy (since I may not have grasp the real indications / outcome here). Thanks, 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] Time for a release
Thomas Keller m...@thomaskeller.biz writes: Its been a while already since 0.41 and I'd like to prepare a new release - probably the last one for 2008 ;) Good. 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). * The buildbots on Win32, Mac OS X and AIX are either dysfunctional or offline. Could somebody (Richard, where are you?) please have a look at them? (Btw... Richard, in case you've missed my email a couple of months ago, please remove the SuSE 9.3 buildbot - this is no longer existing.) I was maintaining the Win32 buildbot; the machine has died. I'm moving to a new house; once I get settled I'll look into replacing it. I can run the monotone test suite on a Win32 machine at work; last I tried it, there were no failures. There are some failures in the Cygwin version; I have not tried to fix them recently. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
In message 86bpveq1kd@stephe-leake.org on Sun, 14 Dec 2008 09:22:10 -0500, Stephen Leake stephen_le...@stephe-leake.org said: stephen_leake * Had anybody beside the implementor taken a deeper stephen_leakelook and tried the new mtn conflicts functionality? stephen_leakeIs this ready to ship as is? stephen_leake stephen_leake not to my knowledge; one person used it and aggreed it stephen_leake was an improvement over the current conflict resolution stephen_leake process (which is still there). Having been absent for a bit, this part is completely new to me (though I think I noticed it when I looked at the commit log at some point), and untried... I'm curious, so I'll read up on it and play a little ;-) Thomas, how soon are you going to make the release? Can I ask for a few days to try new things out? I'm in a playful mood for the moment ;-) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Richard Levitte schrieb: Having been absent for a bit, this part is completely new to me (though I think I noticed it when I looked at the commit log at some point), and untried... I'm curious, so I'll read up on it and play a little ;-) Very cool! Thomas, how soon are you going to make the release? Can I ask for a few days to try new things out? I'm in a playful mood for the moment ;-) Sure, I'm on holidays until the end of this year, so I can do the release almost anytime - I planned to do it by the end of this week or the beginning of the next week. 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] Time for a release
Thomas Keller [EMAIL PROTECTED] writes: Stephen Leake schrieb: I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? No, because 'mtn automate show_conflicts' doesn't show workspace conflicts, so there is no way to generate an appropriate conflicts resolution file. That could be improved in the future, but it will be a lot of work. We need to add new conflict classes for all the workspace conflicts, and change the way the core workspace update code to record the conflicts rather than just reporting them to stderr. You can always commit and merge before update, so this is not a major impediment. I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. Ok. The n.v.m.resolve_conflicts branch is only about half-done, but the general flavor is right, if people want to start looking at it. So if we can postpone a release until next weekend, I'd appreciate it. If the others are ok, I guess we can easily release a few days later. (After all, we've already waited four months...) My wife and son are away from Wednesday, so I guess I'll have more time for different things then anways ;) Ok. On the other hand, the mtn command line interface to this feature is not at all settled. snip Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. I agree it is needed eventually. I'm not clear it is needed immediately. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... That's true; holding merging this to mainline until there is a reasonable command line interface will definitely motivate me to implement it. And I agree that's a reasonable requirement. However, I was hoping that someone else would implement that part. Hmm. I guess it won't be too hard. There is already code that parses the basic-io conflicts representation and stores it in structures, and other code that writes out the structures; adding a command that just read them in, adds one or more resolutions, and writes them back out would not be hard. That same command could use the current need help for merge mechanism on content conflicts, one at a time. It will be difficult to let the user specify which conflict to work on. Always working on the first unresolved conflict would be reasonable, I guess. That way you would just provide resolutions in order; when there are resolutions for all conflicts, you are ready to merge. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
In message [EMAIL PROTECTED] on Sat, 30 Aug 2008 12:48:12 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. This is a script which comes with the source tree; I tried zackw renaming it out of the util/ directory but that did not help. Whoever zackw created that file, please fix this. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? zackw if everything looks reasonable sane, I'd do a release sometime on sunday. zackw zackw I've also done a couple of small updates to the Debian zackw packaging. Please DO NOT follow the instructions in zackw upgrade-checklist.txt for modifying debian/changelog; instead zackw just do zackw zackw $ dch -m --release Someone remind me where that file is... -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Mon, Sep 1, 2008 at 12:10 AM, Richard Levitte [EMAIL PROTECTED] wrote: Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? Possibly just needs putting util/mtnopt in EXTRA_DIST or whatever it's actually called then? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg wrote: On Mon, Sep 1, 2008 at 12:10 AM, Richard Levitte [EMAIL PROTECTED] wrote: Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? Possibly just needs putting util/mtnopt in EXTRA_DIST or whatever it's actually called then? Already fixed 'make distcheck' by moving mtnopt from bin_SCRIPTS to dist_bin_SCRIPTS, adding it to DISTCLEANFILES, and patching it to support '-- help' and '--version' ;) - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
I've just committed db337bc730cc15eae78f94a423bc460823b07e0a. It adds the command 'resolve_conflict' that sets the conflict resolution for the first unresolved conflict in the conflict file. There's a test for it, which isn't passing yet, because it's testing conflict resolutions that are not yet implemented. I also added a command 'automate file_merge' that outputs the result of the internal line merger; useful for checking what a 'resolved_internal' file content conflict will actually be. It's bedtime for today. I have some time tomorrow; I might actually finish the todo list for this. Argh; I forgot to put 'resolve_conflict' in monotone.texi. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller [EMAIL PROTECTED] writes: Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok. I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. This is the biggest impediment to using mtn for my team at work; they are scared of merging, because of the uncertainty involved in the conflict resolution process. This is especially true for propagating between branches; there are typically many small conflicts that must be reviewed. All of the code I need is in n.v.m.automate_show_conflicts, which also implements suture (but not fully yet). I'm subsetting that into n.v.m.resolve_conflicts (yes, the branch names are not the best). Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. So if we can postpone a release until next weekend, I'd appreciate it. On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. This minimal command line interface is sufficient to get things started; we can add more commands for the next release, after people have had a chance to experiment. We can also add resolutions for more conflicts. In the meantime, any text editor can be used to add resolutions to the conflict file; it's in basic-io format. However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Ludovic Brenta schrieb: Thomas Keller writes: So please check NEWS if it contains a note of something you may have done to trunk since 0.40 Speaking of NEWS, it appears that the introduction of suspension certs is documented nowhere in it. I don't even remember what version that was. Could someone please add the appropriate entry, even if that means rewriting history? Well, I guess we don't like to rewrite history, but I added an entry for mtn suspend under 0.41 noting that we've forgot to mention it for 0.37... Thanks for the reminder! Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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] Time for a release
Stephen Leake schrieb: Thomas Keller [EMAIL PROTECTED] writes: Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok. I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. So if we can postpone a release until next weekend, I'd appreciate it. If the others are ok, I guess we can easily release a few days later. (After all, we've already waited four months...) My wife and son are away from Wednesday, so I guess I'll have more time for different things then anways ;) On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. This minimal command line interface is sufficient to get things started; we can add more commands for the next release, after people have had a chance to experiment. We can also add resolutions for more conflicts. In the meantime, any text editor can be used to add resolutions to the conflict file; it's in basic-io format. However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... Other opinions? Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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] Time for a release
On Monday 01 September 2008 Thomas Keller wrote: Stephen Leake schrieb: I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? It should, or at least I would be surprised if it didn't. Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. Do all tests pass? I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. So if we can postpone a release until next weekend, I'd appreciate it. While a review could be done in a week, I'm not sure we should really be in a hurry. We can easily have a 0.42 in a month or so. On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. Yes, I also think that a cmdline interface for recording resolving decisions is needed. Not everyone is using emacs. At least the format of MTN/conflicts must be documented properly. Also, test cases are needed. (Maybe this is already done, didn't find the time yet to have a look at that branch). However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... Other opinions? Not meaning to discourage you, Stephen, but at this time, and with Thomas wearing the release manager cap already, I'd say, we'd better have 0.41 done now, and have your work merged in afterward. Having a 0.42 release within short time then would be fine and fully justified even by a single new feature. But of course the decision is up to Thomas as he's doing the work ;) - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller schrieb: The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? Sorry, I read for show_conflicts now in 0.40 that this is currently not possible - probably because the revision does not yet exists in database. Probably a harder task...? Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. A few small objections (without being dived too deep into the code tonight): I created two small conflicts and tried to merge via mtn merge --resolve-conflicts-file _MTN/conflicts. I did not edit the file yet, so I supposed an error resolution entry missing or something, but I rather got an invariant: roster_merge.cc:1715: invariant 'I(result.attribute_conflicts.size() == 0)' violated As long as we have no user UI this and probably other invariants should become user errors, no? Secondly, there is a FIXME in monotone.texi: FIXME_RESOLVE_CONFLICTS: – added default resolution for file content conflicts Thirdly, I'm missing documentation on the format of conflict resolution stanzas (beside resolved_internal nothing is mentioned) - this and maybe a small example / test workflow could be added to the manual for now? However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... I think I'd go for a compromise: Review the current changes more closely in nvm.resolve-conflicts - if all goes well and it gets merged, we release 0.41 with your branch. If not or any major dealbreakers are found within the next days, we release 0.41 without your branch. Timeline is still until next weekend, if we get ready sooner, we can release earlier - but there will be no later release than next sunday. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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] Time for a release
On Sat, Aug 30, 2008 at 5:23 AM, Thomas Keller [EMAIL PROTECTED] wrote: Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok. make distcheck is failing because it can't find a rule to create mtnopt. This is a script which comes with the source tree; I tried renaming it out of the util/ directory but that did not help. Whoever created that file, please fix this. if everything looks reasonable sane, I'd do a release sometime on sunday. I've also done a couple of small updates to the Debian packaging. Please DO NOT follow the instructions in upgrade-checklist.txt for modifying debian/changelog; instead just do $ dch -m --release and then immediately quit out of the editor. If you do not have access to the dch utility, just change the word UNRELEASED to unstable on the first line of debian/changelog, and replace the date after my email address with the current time (you can use date -R to get it in the right format). Note that there must be two spaces between the email address and the date. I'll handle debian packaging/upload from there. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller writes: So please check NEWS if it contains a note of something you may have done to trunk since 0.40 Speaking of NEWS, it appears that the introduction of suspension certs is documented nowhere in it. I don't even remember what version that was. Could someone please add the appropriate entry, even if that means rewriting history? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Thu, Apr 03, 2008 at 07:07:20PM +0200, Richard Levitte wrote: It's been a little more than a month, and two other branches have been merged in (among others causing a need to migrate the database), so I think it's time for 0.40. Random curiosity: UPGRADE says that each known-server var has to be unset after moving to (what-will-be) 0.40: why is this? I am not seeing anything obvious in the n.v.m log -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Fri, Apr 4, 2008 at 1:24 PM, Jack Lloyd [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2008 at 07:07:20PM +0200, Richard Levitte wrote: It's been a little more than a month, and two other branches have been merged in (among others causing a need to migrate the database), so I think it's time for 0.40. Random curiosity: UPGRADE says that each known-server var has to be unset after moving to (what-will-be) 0.40: why is this? I am not seeing anything obvious in the n.v.m log As of rev d24f04c17774410058c7981a18da726748a3156e you don't have to do that anymore. :-) We went a little overboard with the binary hashes and tried to use them for server fingerprints as well. I've changed it back, because the space hit is too small to worry about, and it's much better UI - no need to drop all the variables on upgrade, ls vars doesn't dump garbage to your screen (or need to have a special case for known-server vars in order not to do that), etc. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
In message [EMAIL PROTECTED] on Fri, 4 Apr 2008 13:24:30 -0400, Jack Lloyd [EMAIL PROTECTED] said: lloyd On Thu, Apr 03, 2008 at 07:07:20PM +0200, Richard Levitte wrote: lloyd It's been a little more than a month, and two other branches have been lloyd merged in (among others causing a need to migrate the database), so I lloyd think it's time for 0.40. lloyd lloyd Random curiosity: UPGRADE says that each known-server var has lloyd to be unset after moving to (what-will-be) 0.40: why is this? I lloyd am not seeing anything obvious in the n.v.m log It's an effect of the following NEWS items: - The database scheme has been changed to store binary encoded hashes, instead of a longer hex encoded representation. That reduces the database size and speeds up operations a little. Users who like to fiddle with the database directly are adviced to use the sqlite function hex(), the built-in quote() function as well as the hexadecimal notation x'DEADBEEF'. - Monotone now uses that same binary hash representation internally as well, saving some conversion steps from and to hex encoded notation. The known-servers entried looked like this before migrating (extracted with 'automate get_db_variables'): domain known-servers entry guardian.lp.se 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e The thing is that migration does nothing with database variables, simply because from a general point of view, monotone doesn't have ANY knowledge about the format of the values. The internal problem is now that the new monotone will have two blobs that it treats as binary, one being the 20 byte binary hash that came from the server, the other (literally) being the 40 bytes composed with the string that came from the variable above. The result, when trying to talk with said server, is this: : ; LANG=C mtn -d DATABASE push [EMAIL PROTECTED] mtn: connecting to guardian.lp.se mtn: @@@ mtn: @ WARNING: SERVER IDENTIFICATION HAS CHANGED @ mtn: @@@ mtn: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY mtn: it is also possible that the server key has just been changed mtn: remote host sent key 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e mtn: I expected 336536663532323562633266616362633230633964653337326461653165323038393265 mtn: 'mtn unset known-servers guardian.lp.se' overrides this check DEBUG[MN]: - start MN_note_netsync_end mtn: warning: /home/levitte/.monotone/monotonerc:69: bad argument #1 to 'pairs' (table expected, got nil) mtn: error: server key changed Note the really long hash that monotone says it expected. That's the hexadecimal representation of the bytes '3', 'e', '6', 'f' and so on: : ; echo -n 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e | od -t x1 000 33 65 36 66 35 32 32 35 62 63 32 66 66 66 61 63 020 62 63 32 30 63 39 64 65 33 37 66 66 32 64 61 65 040 31 65 32 30 38 39 32 65 050 Now, if I remove the above database variable and do a push again, the push will tell me that it got a new server cert with the hash 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e and will now store that hash in its internal representation: domain known-servers entry guardian.lp.se oR%�/��� ���7�-� . Of course, this could be resolved some other way. We could do this by having the migration code change all database variables in the domain known-servers, or we could change the recommendation in UPGRADE to an SQL line that makes that change. Either is fine by me. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Levitte wrote: I'll do the release in the middle of next week, wednesday or thursday. I hope that will give people enough time to review, fix important bugs, make necessary changes in NEWS, perhaps update the translations? Here is the current status of the translations: rm -f es.gmo /usr/bin/msgfmt -c --statistics -o es.gmo es.po 1122 translated messages, 2 fuzzy translations, 1 untranslated message. rm -f es.gmo /usr/bin/msgfmt -c --statistics -o es.gmo es.po 1125 translated messages. I would appreciate it if anybody changes a string would give a heads up. I try to pay close attention around release week, but sometimes I get distracted. take care nicolás Cheers, Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9ovgmjsZS9ZBxv8RArPtAJ44UDMHIFhLRR6n46ZTKrUfoXLLqACcDezf 9GFH1lKNBpeNGjto+VaQ60I= =R+qF -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release, I think...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Levitte schrieb: I plan to release 0.38 next week. Probably Friday (Dec 7th). It would be high time to double check NEWS, see if some translations need some work and fixing what can be fixed related to different platforms (see the buildbot page). AFAIR Matt did a small, but very noticable change wrt merging in 139613dd1ee3f2c7e4b0578aaacf1d8a67f240d9. We got pretty often complains that a complex merge result was abandoned just because no or a wrong key was given. Matt, could you add this to NEWS, please? And again to all, please remember to add user visible / noticable changes directly into NEWS so we don't forget about them for the next release... Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Für Freiheit und gegen staatliche Überwachungsmaßnahmen: http://leipzig.vorratsdatenspeicherung.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHU+pPaf7NlBYNEJIRAoxAAJ926t3X41eCusORGb28z6qMAIQrkgCgrdRp tw0xa/9A8C+ZFBUwiGcqyxc= =Is4i -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
