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
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] Extended selectors
Timothy Brownawell writes: > I have a branch net.venge.monotone.extended-selectors that allows > selectors to use graph operations, and be combined with 'or' as well > as 'and'. > > It allows things like for example > mtn diff -r 'lca(h:*extended-selectors;h:net.venge.monotone)' -r > h:*extended-selectors Great! This has been a personal request of mine for years, see https://savannah.nongnu.org/bugs/?18302 > The additional things you can do with selectors are: >foo|bar|baz I would prefer another character; the pipe needs quoting in most shells. Maybe ^? > 'or' (to go with the foo/bar/baz 'and' we already have) >(foo|bar)/(baz|qux) > grouping parentheses, directly mixing '/' and '|' is actually > forbidden so you can't get confused about what it will do Great; just like in Ada! Thanks a lot for all your hard work. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Extended selectors
Am Freitag, den 04.06.2010, 11:15 +0200 schrieb Ludovic Brenta: > > It allows things like for example > > mtn diff -r 'lca(h:*extended-selectors;h:net.venge.monotone)' -r > > h:*extended-selectors > I would prefer another character; the pipe needs quoting in most > shells. Maybe ^? ^ is ancient shell for pipe, so it's just as fragile (with the additional disadvantage that people don't know about it anymore). Parentheses must also be quoted for some shells, so it's probably okay to just use | (which is probably more commonly understood as 'or' due to regular expressions using it), and expect users to understand that they'll need quoting, like in the example above. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Buildbot slaves
Am 29.04.2010 17:11, schrieb Richard Levitte: > I've just reorganizzed the buildbot a bit, since I noticed most of > the slaves haven't been online for ages. There are now three status > pages: > > The main results page: http://monotone.ca/buildbot/ > Upcoming slaves (such as Lester's): http://monotone.ca:9010/ Whats the status of these two bots? They don't seem to build anything... 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
[Monotone-devel] Absurdly long check-out duration (probable bug)
Attempting: $ mtn db init -d mtn.db $ mtn pull -d mtn.db monotone.ca 'net.venge.monotone.*' with monotone 0.47 under Linux, midway though the checkout CPU usage remained high but no more revisions came in. Seven hours later at 100% CPU usage, I killed the process. This looks like a bug. I tried the 0.46 Linux binary from the monotone web-site and it seemed to have the same issue (although I didn't run it for as long as 0.47). I had no issues with the 0.45 binary, which completed the checkout in around 20 mins. I guess something in monotone branches is giving it the issue, as pulling just 'net.venge.monotone' works fine for me. Can others replicate? I guess try locally if possible to avoid undue stress on monotone.ca. Francis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Absurdly long check-out duration (probable bug)
On 06/04/2010 03:40 PM, Francis Russell wrote:
Attempting:
$ mtn db init -d mtn.db
$ mtn pull -d mtn.db monotone.ca 'net.venge.monotone.*'
with monotone 0.47 under Linux, midway though the checkout CPU usage
remained high but no more revisions came in. Seven hours later at 100%
CPU usage, I killed the process. This looks like a bug.
I tried the 0.46 Linux binary from the monotone web-site and it seemed
to have the same issue (although I didn't run it for as long as 0.47). I
had no issues with the 0.45 binary, which completed the checkout in
around 20 mins.
I guess something in monotone branches is giving it the issue, as
pulling just 'net.venge.monotone' works fine for me.
Can others replicate? I guess try locally if possible to avoid undue
stress on monotone.ca.
What's happening is that at some point during the pull, a branch is
getting a new head which is not a close relation of all the existing
heads. So monotone walks the history graph to see if the new head is a
descendant of the old head or not, but the search function was broken so
that multiple paths through the same revisions aren't pruned.
This should fix it, will commit shortly.
$ mtn diff
#
# old_revision [2260b4d7a1bf77381a5dcd7fde3654b20d2f57a1]
#
# patch "database.cc"
# from [22e4b9ab811ee3efcd5a166a67094e259ea8190a]
#to [0bc6ce7bb27323c3724ee95f099985a3abad21f3]
#
--- database.cc 22e4b9ab811ee3efcd5a166a67094e259ea8190a
+++ database.cc 0bc6ce7bb27323c3724ee95f099985a3abad21f3
@@ -2655,6 +2655,7 @@ database::is_a_ancestor_of_b(revision_id
vector todo;
todo.push_back(ancestor);
+ set seen;
while (!todo.empty())
{
revision_id anc = todo.back();
@@ -2666,11 +2667,16 @@ database::is_a_ancestor_of_b(revision_id
{
if (*i == child)
return true;
+ else if (seen.find(*i) != seen.end())
+continue;
else
{
get_rev_height(*i, anc_height);
if (child_height > anc_height)
-todo.push_back(*i);
+{
+ seen.insert(*i);
+ todo.push_back(*i);
+}
}
}
}
--
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] Time for a release
Am 03.06.10 13:03, schrieb Thomas Keller: > Am 31.05.2010 01:01, schrieb Thomas Keller: >> 200 diff_patch_drop FAIL (line 29) > > Apparently the BSD version of patch does not drop files - can we make a > guard for that in the test? I've found the man page for patch on openBSD (http://www.openbsd.org/cgi-bin/man.cgi?query=patch) and it contains no mention of special handling of the source / target path "/dev/null". Also, the explanation of the -E (--remove-empty-files) option tells nothing about the automatic removal of empty files, so I guess openBSD's patch always needs an explicit -E given to do what patch does automatically on other platforms. Even if it would do what it should, if the environment variable "POSIXLY_CORRECT" is found, it acts as if it would be argumented with --posix, which makes it leave empty files alone again. So, what should we do here? The addition of -E for all other unices would mean that we'd tamper the test. We check there whether the diff input is so well-formed that a "normal" unix patch would act correctly and remove the file if it is empty. If we would always give -E, patch would remove it every time (as long as it is empty), even if it does not have the correct header (change a test diff to use /dev/nul instead of /dev/nul, f.e., to see the effect - the file is no longer removed on "compliant" systems). Do we care enough to skip this test altogether on freebsd and openbsd or should we just parametricize patch with -E only on these platforms? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller 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
