Re: [Monotone-devel] monotone 0.48 released
Thomas Keller m...@thomaskeller.biz writes: We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work on this, and everyone else's, too. After the releasek, you bumped the version to 0.99dev. It was suggested to use 0.90 instead, in case we need 0.91 before 1.0. I think that's a good idea. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] overwriteable and negatable options
Timothy Brownawell tbrow...@prjek.net writes: On 06/13/2010 08:25 PM, Stephen Leake wrote: I tweaked a couple comments, and enhanced tests/default_command_options to show that command line options override get_default_command_options. However, the test is failing, because --verbose --no-verbose leaves verbosity set at 1. I tried running in the debugger, but I can't see why that's happening. The --verbose flag was in it's own optset, which was different from the one that the 'verbose' variable was is. So resetting didn't actually change the 'verbose' variable. It was in its own optset because 'db complete' used it, but since it's global I make 'db complete' not specifically take it and put in the same optset as the other verbosity options and the variable. Ah, that makes sense. Should 'full' also be in the verbosity optset? It's now deprecated, but it might as well work with --no-verbose, and serve as an example of how to do this right. We should have a process for actually deleting deprecated stuff; that means keeping track of what release it was first deprecated in. Then we delete it two releases later, or one year later, or something. I guess we can use mtn annotate for that, but a version field in the macro might be better. It doesn't have to be part of the message, just a forced comment that can be reviewed at release time. I added HIDE on no-prefix, since I introduced that for testing a while ago. I think 'move-conflicting-paths' should have '/no-move-conflicting-paths'; that is one I would like to set in get_default_command_options. Is there some reason it doesn't? GOPT(format_dates ...) could be GLOBAL_SIMPLE_OPTION? I don't think we can change 'without-header', 'with-header' to 'with-header/without-header', because the resetter would also reset 'reverse'. We should probably add a comment about that. Or we could not have 'with-header' and 'reverse' in the same optset; then they have to be specified separately in CMD option lists. Similarly for 'automate_inventory_opts' 'no-unknown' vs 'unknown' 'unknown'; we don't want 'no-unknown' to reset the other automate_inventory_opts. I don't think this is a problem for these particular options; we don't need resetters in general for automate options. This use of OPTSET for two different purposes (grouping and resetting) will get confusing. Would it be possible to specify the reset option name in the OPTSET macro? That would be clearer. Each optset has a full options_type entry in all_options, so the resetter could be stored there, rather than with each individual option. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
Thomas Keller m...@thomaskeller.biz writes: Am 14.06.2010 11:08, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work on this, and everyone else's, too. After the releasek, you bumped the version to 0.99dev. It was suggested to use 0.90 instead, in case we need 0.91 before 1.0. I think that's a good idea. Well, actually we don't want another point release between 0.99 and 1.0. We certainly don't want to plan on that, but allowing for it seems reasonable. We should concentrate on getting 0.99 stable and out within the next couple of weeks and then finalize i18n and fix open bugs from 0.99 for 1.0. And I plan to make the time span between 0.99 and 1.0 reasonably long enough to let enough people find bugs which we can fix by then. Having more minor steps between 0.9x and 1.0 just makes it harder to stop people merging features into mainline during that time... i.e. hey, stabilizing these new things shouldn't be a problem, we have a couple of more point releases left, right?!. Perhaps we can use 0.99 this time, but plan on 1.90 before 2.0. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #18302] Selector syntax to select the common ancestor revision
Update of bug #18302 (project monotone): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: Version 0.99 will introduce an lca selector function, so to follow your example, the following would do what you want (if you are in the private workspace): $ mtn di -r lca(h:upstream;h:) -r h:upstream so I'm marking this feature request as fixed. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18302 ___ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
On 06/14/2010 04:37 AM, Thomas Keller wrote: Am 14.06.2010 11:08, schrieb Stephen Leake: Thomas Kellerm...@thomaskeller.biz writes: We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work on this, and everyone else's, too. After the releasek, you bumped the version to 0.99dev. It was suggested to use 0.90 instead, in case we need 0.91 before 1.0. I think that's a good idea. Well, actually we don't want another point release between 0.99 and 1.0. We should concentrate on getting 0.99 stable and out within the next couple of weeks and then finalize i18n and fix open bugs from 0.99 for 1.0. And I plan to make the time span between 0.99 and 1.0 reasonably long enough to let enough people find bugs which we can fix by then. Having more minor steps between 0.9x and 1.0 just makes it harder to stop people merging features into mainline during that time... i.e. hey, stabilizing these new things shouldn't be a problem, we have a couple of more point releases left, right?!. And if we really, really need another pre-release for some weird reason (which I doubt, though), we can still make an 1.0 release candidate. 0.99, 0.999, 0., etc also sorts properly, and emphasizes the idea that each one is supposed to be the last before 1.0. (Also, I have this old can of green paint sitting around. Let's use that.) -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
On Mon, Jun 14, 2010 at 12:55 AM, Thomas Keller m...@thomaskeller.biz wrote: Hi! We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work! Windows version is available. -- Minor heads up for release manager. t:monotone-0.48 doesn't build on win32 because of compilation error. Error is trivial (patch attached) and Windows version of monotone-0.48 will not exactly match revision tagged as monotone-0.48. (anyone who made this change in win32/parse_date.cc ... if you don't have win32 build env in under your hand please ping me even using private e-mail and i can recheck build before release, unfortunately i can't supply mingw32 buildbot). -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / monotone_0.48_mingw_fix.patch Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
Am 14.06.2010 14:44, schrieb Zbigniew Zagórski: On Mon, Jun 14, 2010 at 12:55 AM, Thomas Keller m...@thomaskeller.biz mailto:m...@thomaskeller.biz wrote: Hi! We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work! Windows version is available. Thanks for the build! Minor heads up for release manager. t:monotone-0.48 doesn't build on win32 because of compilation error. Error is trivial (patch attached) and Windows version of monotone-0.48 will not exactly match revision tagged as monotone-0.48. (anyone who made this change in win32/parse_date.cc ... if you don't have win32 build env in under your hand please ping me even using private e-mail and i can recheck build before release, unfortunately i can't supply mingw32 buildbot). Uh, wow, this comes totally unexpected. Stephe worked together with Derek in this area, Stephe, can you confirm that this is / was a problem? I'll probably release a 0.48.1 for that if this can be confirmed - unfortunately I don't have a Win box around here. Thanks in either case for the ping offer! 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] 0.99, 0.999, ...
On Mon, Jun 14, 2010 at 07:41:14AM -0500, Timothy Brownawell wrote: On 06/14/2010 04:37 AM, Thomas Keller wrote: Am 14.06.2010 11:08, schrieb Stephen Leake: Thomas Kellerm...@thomaskeller.biz writes: We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work on this, and everyone else's, too. After the releasek, you bumped the version to 0.99dev. It was suggested to use 0.90 instead, in case we need 0.91 before 1.0. I think that's a good idea. Well, actually we don't want another point release between 0.99 and 1.0. We should concentrate on getting 0.99 stable and out within the next couple of weeks and then finalize i18n and fix open bugs from 0.99 for 1.0. And I plan to make the time span between 0.99 and 1.0 reasonably long enough to let enough people find bugs which we can fix by then. Having more minor steps between 0.9x and 1.0 just makes it harder to stop people merging features into mainline during that time... i.e. hey, stabilizing these new things shouldn't be a problem, we have a couple of more point releases left, right?!. And if we really, really need another pre-release for some weird reason (which I doubt, though), we can still make an 1.0 release candidate. 0.99, 0.999, 0., etc also sorts properly, and emphasizes the idea that each one is supposed to be the last before 1.0. I wasn't around back then so I don't know: When monotone started, did it start as 0.01, 0.02, ... 0.09, 0.10, 0.11, ... or did it start 0.1, 0.2, ... 0.9, 0.10? If the former, we're using two-digit integers, but they could be interpreted as rationals, so we haven't run out. If the latter, the next would be 0.100. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.99, 0.999, ...
Am Mon, 14 Jun 2010 10:33:57 -0400 schrieb hend...@topoi.pooq.com: When monotone started, did it start as 0.01, 0.02, ... 0.09, 0.10, 0.11, ... or did it start 0.1, 0.2, ... 0.9, 0.10? If the former, we're using two-digit integers, but they could be interpreted as rationals, so we haven't run out. If the latter, the next would be 0.100. The first commit in my db here (on 2003-09-04, from Graydon) has the commit message: 0.4 release. So, from that point of view, 0.100 would indeed be the next after 0.99, if we don't want to release 1.0. But we should try to avoid going that route again. - Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] What's up with 'warning: including missing parent'?
I think this is new in 0.48: $ mtn ci readme.txt doc/log.txt configure.py -m Tick to 1.9.9-dev mtn: warning: including missing parent '' mtn: warning: including missing parent 'doc' [...] Kind of obnoxious; I can understand if there was a change in the directory, or if the directory wasn't checked in, but that wasn't the case here. $ mtn version --full monotone 0.48 (base revision: 844268c137aaa783aa800a9c16ae61edda80ecea) Running on : Linux 2.6.34-gentoo-1 #1 SMP Wed Jun 9 09:59:46 EDT 2010 x86_64 C++ compiler: GNU C++ version 4.5.0 C++ standard library: GNU libstdc++ version 20100414 Boost version : 1_42 SQLite version : 3.6.23.1 (compiled against 3.6.23.1) Lua version : Lua 5.1 PCRE version: 7.9 2009-04-11 (compiled against 7.9) Botan version : 1.8.8 (compiled against 1.8.8) Changes since base revision: format_version 1 new_manifest [86bede3ba4251594f3a0f7e0c31560f9f8ce3744] old_revision [844268c137aaa783aa800a9c16ae61edda80ecea] Generated from data cached in the distribution; further changes may have been made. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] verbosity options
On Sun, Jun 13, 2010 at 7:06 AM, Timothy Brownawell tbrow...@prjek.net wrote: On 06/13/2010 07:18 AM, Stephen Leake wrote: That could be reasonable, replace all four with a global --verbosity=-2,-1,0,1. Probably this should be part of resettable options, since --quiet and --reallyquiet need to be fixed anyway and can be made resettable along the way. For now, any objections to deleting quiet and reallyquiet from nvm? They turn off tickers and P() messages, and --reallyquiet also turns off W() messages. We probably want to keep them. I support mapping these options to a verbosity level internally, but please keep --quiet around [and its aliases -q and --silent] as a user visible option. Lots of commands recognize -q/--quiet/--silent as meaning no output except in case of errors (or in some cases no output other than exit status, e.g. grep(1)) and we want to keep that global consistency. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
Thomas Keller m...@thomaskeller.biz writes: t:monotone-0.48 doesn't build on win32 because of compilation error. Error is trivial (patch attached) and Windows version of monotone-0.48 will not exactly match revision tagged as monotone-0.48. (anyone who made this change in win32/parse_date.cc ... if you don't have win32 build env in under your hand please ping me even using private e-mail and i can recheck build before release, unfortunately i can't supply mingw32 buildbot). Uh, wow, this comes totally unexpected. Stephe worked together with Derek in this area, Stephe, can you confirm that this is / was a problem? I'll probably release a 0.48.1 for that if this can be confirmed - unfortunately I don't have a Win box around here. It is a problem, and I did notice it over the weekend. But I was focussed on the nvm.options branch, and forgot that this would be a problem for the release. It's actually due to a cleanup of base.hh stuff, not directly related to the parse_date.cc work. This was fixed in unix/parse_date.cc last week: $ mtn annotate unix/parse_date.cc ff193643.. by derek 2010-06-06: #include sanity.hh The win32/parse_date.cc patch is in main: $ mtn annotate win32/parse_date.cc be98c1aa.. by zbigg 2010-06-14: #include sanity.hh Without a complete set of buildbots, perhaps we need a more formal poll of build targets for each release. Personally, I would much rather respond to such polls than maintain a buildbot (I did maintain a buildbot for a while; it was a pain). Another reason to create a release branch for 0.99 and later releases; main can move on while the polling happens. Actually, I think we need a release branch now, to commit this change. Main has moved on from the release point. I have not verified that the recent changes in monotone.iss that zbigg made work on my machine, but I think it's enough that they work on his. For 1.0, we should get more than one person to confirm each target; there are some variations on each target, and we need to confirm that INSTALL is up to date. One way to manage this would be to put release-critical bugs in Savannah, assigned to the build testers. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] What's up with 'warning: including missing parent'?
On Mon, Jun 14, 2010 at 12:02 PM, Jack Lloyd ll...@randombit.net wrote: I think this is new in 0.48: $ mtn ci readme.txt doc/log.txt configure.py -m Tick to 1.9.9-dev mtn: warning: including missing parent '' mtn: warning: including missing parent 'doc' [...] Kind of obnoxious; I can understand if there was a change in the directory, or if the directory wasn't checked in, but that wasn't the case here. This is indeed new with 0.48. The restriction semantics were changed slightly to include parent directories of explicitly included files. Previously the commit above would have failed saying that the parents were required but not included. This warning doesn't need to be permanent of course so if there's some general sentiment that it should be removed it certainly can be. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] What's up with 'warning: including missing parent'?
On Mon, Jun 14, 2010 at 09:52:21PM -0600, Derek Scherger wrote: This is indeed new with 0.48. The restriction semantics were changed slightly to include parent directories of explicitly included files. Previously the commit above would have failed saying that the parents were required but not included. I don't think this is the case. At least I can't replicate this being an error in 0.47 (and I ci specifically named files all the time and have never run into it being an error, except in the case when the parent directory did not already exist in the db). Here's 0.48: $ mkdir test $ cd test/ $ mtn -d test.mtn db init $ mtn -d test.mtn setup -b net.randombit.test-mtn . $ touch foo $ mtn add foo mtn: adding foo to workspace manifest $ mtn ci . foo -m initial commit mtn: beginning commit on branch 'net.randombit.test-mtn' mtn: committed revision 166d10fed2842b0a39b0710c2b0f2e886d34fda0 $ echo blah foo $ mtn ci foo -m change foo mtn: warning: including missing parent '' mtn: beginning commit on branch 'net.randombit.test-mtn' mtn: committed revision 4089dfcbcdf5006c0a4b47f2c1bced3db7f5eed7 Rerunning the above sequence with 0.47, it behaves identically up until the second commit; no warning in 0.47: $ mtn ci foo -m change foo mtn: beginning commit on branch 'net.randombit.test-mtn' mtn: committed revision 4089dfcbcdf5006c0a4b47f2c1bced3db7f5eed7 -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
