Re: [Monotone-devel] time for a release?
Stephen Leake writes: > Markus Wanner 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?
Markus Wanner 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?
Markus Wanner 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?
In message <4f970a86.5040...@bluegap.ch> on Tue, 24 Apr 2012 22:18:14 +0200, Markus Wanner 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
[Monotone-devel] time for a release?
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. How much time do we need to be able to release? Any pending items somebody absolutely wants to get in? Regards Markus Wanner ___ 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 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 : > >> 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 18:26, schrieb Zack Weinberg: > On Sat, Jun 5, 2010 at 4:59 AM, Thomas Keller 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 05.06.10 01:26, schrieb Zack Weinberg: > On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller 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
On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller 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 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
Am Fri, 04 Jun 2010 01:45:44 +0200 schrieb Thomas Keller : > 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 04.06.2010 05:46, schrieb Derek Scherger: > On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller 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 04.06.2010 05:53, schrieb Derek Scherger: > On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller 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
On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller 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
On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller 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
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, 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 ___ 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
Hi, 2010/5/31 Zbigniew Zagórski : > 2010/5/31 Thomas Keller : >> 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 : > 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 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
[Monotone-devel] Time for a release
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. Here is the current status of the translations: sv: 1329 translated, 5 fuzzy, 62 untranslated. it: 1208 translated, 3 fuzzy, 185 untranslated. de: 1449 translated. es: 1249 translated, 64 fuzzy, 83 untranslated. pt: 1389 translated, 4 fuzzy, 3 untranslated. 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? 2) The openBSD one currently fails 5 tests: 101 automate_show_conflicts_defaults FAIL (line 76) 118 branch_leaves_sync_bug FAIL (line 47) 200 diff_patch_drop FAIL (line 29) 206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52) 288 log_--diffs unexpected success 301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22) Is anybody on openBSD and could please have a look here? 3) The Fedora / openSUSE build is currently not functional as well because of the make dist issue in 1) - I still have to improve the error handling for cases like this there. 4) For me on Mac OS X all tests run through, even one unexpectedly (log_--diff) - Derek, should this test be un-xfailed? 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 :) Thanks for your time and 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 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 18.05.2010 07:03, schrieb Derek Scherger: > On Mon, May 17, 2010 at 2:33 AM, Thomas Keller 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?
On Mon, May 17, 2010 at 2:33 AM, Thomas Keller 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?
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?
Thomas Keller 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 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
[Monotone-devel] time for a release?
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? -- -- Stephe ___ 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 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
Am 06.03.10 00:28, schrieb Thomas Keller: > 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. Ok, this was entirely a local problem - there was for some stupid reason an _MTN directory directly in /. 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
Timothy Brownawell 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
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 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-devel] Time for a release
pedump can list what a program is linked to... http://www.wheaty.net/ On Mon, Mar 8, 2010 at 6:11 AM, Timothy Brownawell 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-devel] Time for a release
Hi! 2010/3/8 Timothy Brownawell > 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
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'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
Re: [Monotone-devel] Time for a release
Thomas Keller 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
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-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 on Thu, 4 Mar 2010 11:15:46 -0800, Zack Weinberg 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 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
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 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
[Monotone-devel] Time for a release
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 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 : > 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 ___ 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 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 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
Thomas Keller 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
*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 on Wed, 6 Jan 2010 11:46:49 -0800, Zack Weinberg 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 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
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 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
[Monotone-devel] Time for a release
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 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
Zack Weinberg wrote: > On Sat, Sep 12, 2009 at 12:45 AM, Lapo Luchini 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 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
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
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
Thomas Keller writes: > I'd like to release the next version of monotone on Friday evening, > around 10pm MEST. I'd like to see some progress on the Cygwin package for this release. I rely on Cygwin for 'sync ssh:' to our central server, and 'sync file:' to a USB flash disk. For everything else I use the MinGW build. So normally I can use an old Cygwin version. But since the database needs to be migrated with this version, a Cygwin release is needed. I can help put it together. At the very least, I'd like to see a README.Cygwin documenting what is known so far about building the Cygwin package. As a fallback, I can build a Cygwin mtn executable and distribute it to my team outside the Cygwin package manager, but that's much less than optimal. Many others using Windows will need the Cygwin version for the same reasons I do. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Time for a release
Hi all! I'd like to release the next version of monotone on Friday evening, around 10pm MEST. Please look over the NEWS file if all changes you've done went in (I'll check this again, just to be sure, but I can't guarantee that I catch everything properly) and complete your translations. It would be also cool if the buildbots could receive some love until then, because right now most of them are either offline or even fail to configure (missing boost on freebsd 7, missing botan in x86-openbsd, x86-linux-glibc and debian-testing, netsync_negotiation fails on OSX 10.4). We also currently have no (active) buildbot for win32 - it would be cool if somebody could step in and either fix i686-winvista-vs2005 which is offline or could provide a new one. 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 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 said: stephen_leake> Thomas Keller 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
Zack Weinberg schrieb: > On Wed, Mar 11, 2009 at 6:29 PM, Thomas Keller 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
Thomas Keller 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
2009/3/12 Daniel Carosone > > > 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
2009/3/12 Thomas Keller > Derek Scherger schrieb: > > On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller > 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 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
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
Derek Scherger schrieb: > On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller 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 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 Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller 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
On Wed, Mar 11, 2009 at 6:29 PM, Thomas Keller 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. > 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. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Time for a release
Hi all! 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. A few things which have my attention are: 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). 1) The buildbots i386-debian-testing (isn't this 5.0 by now?) and x86-linux-glibc are missing some of the new requiered dependencies, at least botan. 2) The buildbots i386-win32-mingw, i686-winvista-vs2005, p520-aix-vacpp7, x86-openbsd and x86-linux-glibc-icc are offline since quite some time. Could the owners of these bots please step up and bring them back online? 3) The buildbot ppc-osx104#2 still has this sqlite database_dump_load problem. I don't think this is critical and I cannot reproduce the problem on Intel/OSX 10.5.6 either, but if someone is in the mood and has the hardware / software, feel free to give it a try. 4) The translations need some love: de.po (this is obviously my job): 1247 translated, 9 fuzzy, 13 untranslated es.po: 1174 translated, 49 fuzzy, 46 untranslated sv.po: 1199 translated, 35 fuzzy, 35 untranslated it.po: 1155 translated, 20 fuzzy, 94 untranslated 5) A lot of new and exciting stuff went into NEWS recently, but please ensure that smaller things you've done since 0.42 don't get noticed. I'll skim over the log between 0.42 and the head as well, but I might forget stuff as well. I'll probably also reorder some of the NEWS items on importance, i.e. let the exciting stuff come first. 6) Derek, whats up with nvm.experiment.binary-roster-deltas, nvm.changelog-editor and nvm.experiment.log-options? Should any of those get part of 0.43? 7) Whats up with net.venge.monotone.rename-guess, Matt? Tests are still missing there, but this shouldn't be much work. I just don't want to see your work fading into the background... So long, thanks for reading. 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
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
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
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
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
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
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
In message <86bpveq1kd@stephe-leake.org> on Sun, 14 Dec 2008 09:22:10 -0500, Stephen Leake said: stephen_leake> > * Had anybody beside the implementor taken a deeper stephen_leake> > look and tried the new mtn conflicts functionality? stephen_leake> > Is 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
Thomas Keller 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
[Monotone-devel] Time for a release
Hi all! Its been a while already since 0.41 and I'd like to prepare a new release - probably the last one for 2008 ;) 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? * 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? :) * 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.) * Translators, are you still out there? The Swedish and Italian translations are slightly outdated, the Japanese (last updated Jan 2007), Portuguese (last updated July 2007) and French (last updated June 2006) ones are missing 300+ strings - anybody up for helping out here / taking these over? Other than that I'd really like to see some movement on the server front. As it is now Richard, who was not seen in the last couple of months, manages the server alone, which kind of hinders our final steps for the ikiwiki migration. Richard, do you have some spare time left to do the final setup or, alternatively, could give some other trusted monotone fellow a shell login with which (s)he is able to manage the website, crons and monotone server on monotone.ca? 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
I've got a lot done, but n.v.m.resolve_conflicts is not ready for a release. In particular, the new user commands for specifying resolutions in the conflict file are not quite functional, and they need a lot of improvement in error handling and consistency checking. I'll keep working on it, but I don't have much time between now and Sunday. So it will not be ready for this release. Thanks for your patience and accommodation, -- -- 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'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
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
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
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
Thomas Keller <[EMAIL PROTECTED]> writes: > 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? Yes. Can you post your test case? I don't have any attribute conflicts test cases yet; I wasn't planning on providing resolutions for them, but I agree this is not a good error message. How about "no resolution specified for attribute conflicts; attribute conflict resolutions currently not supported"? Which raises another issue for the 'merge to main' requirements; is just providing resolutions for content and duplicate name enough? Are there other conflict classes that people find particularly cumbersome to deal with? > Secondly, there is a FIXME in monotone.texi: > > FIXME_RESOLVE_CONFLICTS: – added default resolution for file content > conflicts Right; that's my todo list. Which I'm planning to get done this week. > 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? Right; also on my todo list. Another point about the code; the current committed revision ee57fe487ffcfd442877e9f43cf6c952fa585ecf allows 'resolve_conflict_opts' even on workspace merge commands. That was before I remembered that there is now way to generate the conflicts file. So I'm taking those out. > 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. That works for me. The current code is about half done. I'll post updates as I finish things. -- -- 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 Moschny <[EMAIL PROTECTED]> writes: > On Monday 01 September 2008 Thomas Keller wrote: >> Stephen Leake schrieb: >> >> > 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? Yes, and I'm adding new ones for this 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. > > 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. That would be fine. >> > On the other hand, the mtn command line interface to this feature is >> > not at all settled. >> > >> > > > Yes, I also think that a cmdline interface for recording resolving decisions > is needed. Not everyone is using emacs. Ok. Is anyone interested in helping to implement that command line interface? > At least the format of MTN/conflicts must be documented properly. That will be done, in the 'automate show_conflicts' section of the monotone manual, and the various resolutions will be in the 'resolve conflicts' section. > Also, test cases are needed. (Maybe this is already done, didn't > find the time yet to have a look at that branch). There will be complete Lua tests for this feature; some are there already. >> > 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 ;) One issue is who will have time to do the 0.42 release in a month. I could volunteer to be the release manager next time; I'm not sure others would be comfortable with that, since I'm relatively new here. On the other hand, there's no guarantee Thomas Keller will have time in a month, either :). Doing an internal interim monotone release just for my team is a reasonable work-around. Reviewing all the times I've said "that will be done" in this thread, it's looking less likely that it will actually be done this weekend :(. -- -- 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: > 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. >> >> >> >> 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
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 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
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
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
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
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 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
[Monotone-devel] Time for a release
Hi all! 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. If Richard is too busy right now, I'd do the release manager work this time, if he's ok with that. So please check NEWS if it contains a note of something you may have done to trunk since 0.40, especially check the spelling there (I'm not a native, so I may have overlooked something) - if everything looks reasonable sane, I'd do a release sometime on 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
-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
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
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
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
[Monotone-devel] Time for a release
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. 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: # ( cd po; rm *.gmo; make MSGMERGE=msgmerge MSGMERGE_UPDATE='msgmerge --update' ) rm -f fr.gmo && /usr/bin/msgfmt -c --statistics -o fr.gmo fr.po 744 translated messages, 189 fuzzy translations, 192 untranslated messages. rm -f ja.gmo && /usr/bin/msgfmt -c --statistics -o ja.gmo ja.po 586 translated messages, 249 fuzzy translations, 290 untranslated messages. rm -f pt_BR.gmo && /usr/bin/msgfmt -c --statistics -o pt_BR.gmo pt_BR.po 747 translated messages, 162 fuzzy translations, 216 untranslated messages. rm -f sv.gmo && /usr/bin/msgfmt -c --statistics -o sv.gmo sv.po 1105 translated messages, 20 untranslated messages. rm -f it.gmo && /usr/bin/msgfmt -c --statistics -o it.gmo it.po 1088 translated messages, 10 fuzzy translations, 27 untranslated messages. rm -f de.gmo && /usr/bin/msgfmt -c --statistics -o de.gmo de.po 1124 translated messages, 1 fuzzy translation. rm -f es.gmo && /usr/bin/msgfmt -c --statistics -o es.gmo es.po 1122 translated messages, 2 fuzzy translations, 1 untranslated message. Cheers, Richard -- 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, 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
[Monotone-devel] Time for a release, I think...
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). 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
