Re: [Monotone-devel] get rev_id of merge
Am 04.05.10 16:18, schrieb Stephen Leake: I'm trying to get the rev_id of a merge, in a Lua test. Can anyone tell me why this doesn't work? I based it on base_revision(). function merged_revision() local workrev = readfile(stderr) local extract = string.gsub(workrev, ^mtn: %[merged%] (%x*)$, %1) This will not work with multi-line string input, because ^ marks the very beginning and $ the very end of the string, not the line. But even if you remove these, you'll only process the replacement of the matched line, while you actually want to extract something. This should work better: local extract = string.match(workrev, mtn: %[merged%] (%x*)) 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] the changelog editor branch is ready for review
On Tue, Apr 20, 2010 at 3:57 PM, Thomas Keller m...@thomaskeller.biz wrote: In the meantime what I would really really want to get rid of are boolean function arguments - so maybe you could start and make the code a little easier to read by passing a more describable enum value...? Agreed. I've replaced the bool with an enum. I tend to agree here and I've reverted it to use the Changes against parent... however I'm now wondering whether displaying the branch names associated with each parent in this section might be useful which makes me wonder again about using Parent: ... and Branch: headers here. This might surely make sense, but where do we stop? If we start listing cert values of *parents* we might start listing the parents of these parents and their certs and... endless loop :) No, I think the parent revision id is enough, really. Everything else should be part of that revision's log output. Heh, ok. Nothing else to do here then. Now this is something which I'd slightly change - I'd love to see this information in the editable area and the hint that the branch changes above the editable area - because its important and might otherwise get easily forgotten, so something like: I'm not particularly fond of the old branch value in the editable area only because it clutters up the otherwise nicely aligned headers. I'm also not sure including the notice that the branch is changing before or after the editable area makes much difference. It may scroll off the top of a terminal if it's too early so it may be better after the editable values. I've left these where they were in the last iteration but I've emphasized the branch change message so it has a better chance of being noticed. You can set EDITOR='emacsclient +15' to get what you want but this is probably not what you want EDITOR set to in general. We'd need to do some more work in the edit_comment hook to get this right. This would be nice to do but I don't think it's critical for getting this branch finished. Instead of giving the editor a jump point (which could be error-prone f.e. if you think about i18n) I'd try to decrease the verbosity of the entry line mainly by removing the warning in line three: Done. I'd like to preserve the option of telling the editor to jump though, and since that's currently done in EDITOR we can all set it to the appropriate value for our translations so that shouldn't be a real problem. And of course I'd remove Revision: and Parent: from the editable area to make it even less verbose, but we've had this discussion before and as I said I'm happy already that my separators made it in ;) Yes, you're arguing for removing these non-editable things and including the non-editable old branch value. I'm arguing for keeping these and not including the old branch value. It's pretty arbitrary either way there's no doubt. My rationale for leaving the Revision and Parent headers in is that without them the nicely aligned headers look a bit odd because they have extra alignment whitespace that is only relevant when those headers do appear in the output from log and status and I'd like to keep the display from these three commands as similar as possible. I think we definitely want to have it for 0.48. And I'm also voting for not discussing this useful feature to death (because then it won't get included at all) - so I'm shutting up now :) I appreciate the feedback all the same. All that remains is to update the manual to include some examples of the new editor display. I should have this done some time this week. Sorry it took me so long to get to this. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] get rev_id of merge
Thomas Keller m...@thomaskeller.biz writes: Am 04.05.10 16:18, schrieb Stephen Leake: I'm trying to get the rev_id of a merge, in a Lua test. Can anyone tell me why this doesn't work? I based it on base_revision(). function merged_revision() local workrev = readfile(stderr) local extract = string.gsub(workrev, ^mtn: %[merged%] (%x*)$, %1) This will not work with multi-line string input, because ^ marks the very beginning and $ the very end of the string, not the line. But even if you remove these, you'll only process the replacement of the matched line, while you actually want to extract something. This should work better: local extract = string.match(workrev, mtn: %[merged%] (%x*)) That does work, and is clearer, but I don't understand the explanation. Why does base_revision work? Not a very important question, but it bothers me. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Bug Hunt Day
Okay, I've submitted my (largely superfluous) vote, which I hope isn't skewed by being 8 hours off of everyone else :) From a rough sense of things, I think I'd rather either the 9th or the 22-23rd, but however that pans out. Looking forward to it. On Sun, May 2, 2010 at 7:15 AM, Thomas Keller m...@thomaskeller.biz wrote: Am 02.05.10 15:02, schrieb Lapo Luchini: Thomas Keller wrote: http://doodle.com/f7wc8cqxz7d6kumx Uh, that's a nice tool. Unfortunately, of those 3 weekends, only 15-16 is free to me and is the one (by far) less voted of the three. =( I think we won't be able to get everybody appearing at a certain time span, thats why I think its the best idea to pick a range where everybody could at least find some time for one slot. From my calculations the best range up until now is 08. - 09. evening - afternoon (11 appearings) 08. - 09. afternoon - morning (10 appearings) 08. all day (10 appearings) 09. all day (10 appearings) 22. - 23. afternoon - morning (9 appearings) 22. - 23. evening - afternoon (9 appearings) @Zbigniew: You can only attend next week? @Derek: Didn't you want to join the party 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 ___ 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] monotone merge error
Stephen Leake stephen_le...@stephe-leake.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: Mando Rodriguez mandorodrig...@gmail.com writes: When attempting to perform a merge we get this : / mtn: 2 heads on branch '0' mtn: merge 1 / 1: mtn: calculating best pair of heads to merge next mtn: [left] 1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598 mtn: [right] 96c815a1768eb25e49bf74ba3d6e6236adefb30a mtn: fatal: error: roster.cc:1826: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()) mtn: this is almost certainly a bug in monotone. I may have time to look at it this weekend. I finally started looking into this. The immediate cause of the crash is an invariant failure in roster.cc:2066 make_roster_for_merge: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()); I rearranged the MM and I lines there so left_uncommon_ancestors would be dumped on --debug, and it is empty. ... I've made some more progress. The database is inconsistent; the table branch_leaves has incorrect entries. I can't reproduce the error, but the fix is simple; run database::recalc_branch_leaves. I added 'mtn db recalc_branch_heads' (not committed), and after running it, 'mtn heads' correctly shows just one head. We could add a check for this to 'mtn db check'; it could compute the branch leaves and compare to the current values in the branch_leaves table. If no one objects, I'll check in the 'db recalc_branch_heads' command, and work on a new check in 'db check'. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [ANN] monotone Bug Hunt Day
Hi everyone! I'd like to announce the second iteration of the monotone bug hunt day. This happening will take place between Sat 08.05. 18:00 UTC and Sun 09.05. 18:00 UTC which should lead to the most appearances (14) of interested developers. Please ensure that you have a Savannah account and that you've added yourself to the monotone project there. The rules for working on the bugs are simple: 1) Pick a bug (and only one bug at a time to avoid blocking others) you would like to work on and assign the ticket to you 2) Create a new branch nvm.bugfest-2010.savane-bug-id-savane-login and work on the fix. If the fix is non-trivial, please also add an accompanying functional test. Don't forget to describe your fix shortly in NEWS. 3) If the bug is fixed, set the ticket on In test, post the last revision or alternatively the branch name again in the ticket and go on to the next. After the bug hunting has been finished, we are going to quality-review the fixes / changes of the attendees collaboratively, close the tickets and merge the changes back into the main trunk if everything is ok. We will also collaboratively give points for the fixes afterwards, which then may range from one point for trivial ones or fixes like works with the current version to eight points for complex fixtures or the implementation of feature requests (in Scrum manner only 1, 2, 3, 5 and 8 are allowed - we could then misuse a tool like planningpoker.com to get to a common point number). The three people with the most points in the end get a present from me from our new cafepress shop at http://www.cafepress.com/monotone_rcs: For the winner: one item up to 25 US-$ For the first runner-up: one item up to 20 US-$ For the second runner-up: one item up to 15 US-$ If you have further question, don't hesitate to ask them here. In the meantime, thanks for your interest and see you on Saturday! 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] the changelog editor branch is ready for review
Am 05.05.2010 07:11, schrieb Derek Scherger: On Tue, Apr 20, 2010 at 3:57 PM, Thomas Keller m...@thomaskeller.biz wrote: And of course I'd remove Revision: and Parent: from the editable area to make it even less verbose, but we've had this discussion before and as I said I'm happy already that my separators made it in ;) Yes, you're arguing for removing these non-editable things and including the non-editable old branch value. I'm arguing for keeping these and not including the old branch value. It's pretty arbitrary either way there's no doubt. Ok, you're right, I was not consistent here. Maybe I thought more of only show actual (editable) cert values in the editable area - both Parent: and Revision: are clearly not certs at all. My rationale for leaving the Revision and Parent headers in is that without them the nicely aligned headers look a bit odd because they have extra alignment whitespace that is only relevant when those headers do appear in the output from log and status and I'd like to keep the display from these three commands as similar as possible. Ok, as I said earlier, I don't want to argue on these two extra lines too much and I see this as trade-off between consistency with other command's output and cleanness of the editor's contents now. I think we definitely want to have it for 0.48. And I'm also voting for not discussing this useful feature to death (because then it won't get included at all) - so I'm shutting up now :) I appreciate the feedback all the same. All that remains is to update the manual to include some examples of the new editor display. I should have this done some time this week. Ok, cool! 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] monotone merge error
Am 05.05.10 09:13, schrieb Stephen Leake: Stephen Leake stephen_le...@stephe-leake.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: Mando Rodriguez mandorodrig...@gmail.com writes: When attempting to perform a merge we get this : / mtn: 2 heads on branch '0' mtn: merge 1 / 1: mtn: calculating best pair of heads to merge next mtn: [left] 1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598 mtn: [right] 96c815a1768eb25e49bf74ba3d6e6236adefb30a mtn: fatal: error: roster.cc:1826: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()) mtn: this is almost certainly a bug in monotone. I may have time to look at it this weekend. I finally started looking into this. The immediate cause of the crash is an invariant failure in roster.cc:2066 make_roster_for_merge: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()); I rearranged the MM and I lines there so left_uncommon_ancestors would be dumped on --debug, and it is empty. ... I've made some more progress. The database is inconsistent; the table branch_leaves has incorrect entries. I can't reproduce the error, but the fix is simple; run database::recalc_branch_leaves. As far as I remember this table is quite new and was added by Tim last November to speed up certain things - maybe it would be a good idea if he could have a look into the issue as well...? I added 'mtn db recalc_branch_heads' (not committed), and after running it, 'mtn heads' correctly shows just one head. We could add a check for this to 'mtn db check'; it could compute the branch leaves and compare to the current values in the branch_leaves table. If no one objects, I'll check in the 'db recalc_branch_heads' command, and work on a new check in 'db check'. The check is definitely a good idea - if we want a separate recalc_branch_heads command is questionable - for two reasons: 1) I fear we fix something whose original cause we still haven't understood - as you correctly stated in one of your previous mails Before we discuss committing that change, we need to understand why mtn thinks this graph has two heads, and how it got that way. 2) If we cannot track the problem down and find any other way than regenerating the branch leave cache to fix the problem, then I'd propose we call recalc_branch_leaves as part of the `db regenerate_caches` command (if it doesn't take so long to additionally recalculate them). Thanks a lot for your findings so far! 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] get rev_id of merge
Am 05.05.10 09:02, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: Am 04.05.10 16:18, schrieb Stephen Leake: I'm trying to get the rev_id of a merge, in a Lua test. Can anyone tell me why this doesn't work? I based it on base_revision(). function merged_revision() local workrev = readfile(stderr) local extract = string.gsub(workrev, ^mtn: %[merged%] (%x*)$, %1) This will not work with multi-line string input, because ^ marks the very beginning and $ the very end of the string, not the line. But even if you remove these, you'll only process the replacement of the matched line, while you actually want to extract something. This should work better: local extract = string.match(workrev, mtn: %[merged%] (%x*)) That does work, and is clearer, but I don't understand the explanation. Why does base_revision work? Not a very important question, but it bothers me. I think this works because of the .* before and after the search pattern. I tried this locally before as well, but couldn't get it to 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] monotone merge error
Thomas Keller m...@thomaskeller.biz writes: Am 05.05.10 09:13, schrieb Stephen Leake: Stephen Leake stephen_le...@stephe-leake.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: Mando Rodriguez mandorodrig...@gmail.com writes: When attempting to perform a merge we get this : / mtn: 2 heads on branch '0' mtn: merge 1 / 1: mtn: calculating best pair of heads to merge next mtn: [left] 1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598 mtn: [right] 96c815a1768eb25e49bf74ba3d6e6236adefb30a mtn: fatal: error: roster.cc:1826: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()) mtn: this is almost certainly a bug in monotone. I may have time to look at it this weekend. I finally started looking into this. The immediate cause of the crash is an invariant failure in roster.cc:2066 make_roster_for_merge: I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end()); I rearranged the MM and I lines there so left_uncommon_ancestors would be dumped on --debug, and it is empty. ... I've made some more progress. The database is inconsistent; the table branch_leaves has incorrect entries. I can't reproduce the error, but the fix is simple; run database::recalc_branch_leaves. As far as I remember this table is quite new and was added by Tim last November to speed up certain things - maybe it would be a good idea if he could have a look into the issue as well...? I added 'mtn db recalc_branch_heads' (not committed), and after running it, 'mtn heads' correctly shows just one head. We could add a check for this to 'mtn db check'; it could compute the branch leaves and compare to the current values in the branch_leaves table. If no one objects, I'll check in the 'db recalc_branch_heads' command, and work on a new check in 'db check'. The check is definitely a good idea - Ok. if we want a separate recalc_branch_heads command is questionable - for two reasons: 1) I fear we fix something whose original cause we still haven't understood - as you correctly stated in one of your previous mails Before we discuss committing that change, we need to understand why mtn thinks this graph has two heads, and how it got that way. Ok. But we need some workaround to fix the problem until we do find the real cause. 2) If we cannot track the problem down and find any other way than regenerating the branch leave cache to fix the problem, then I'd propose we call recalc_branch_leaves as part of the `db regenerate_caches` command (if it doesn't take so long to additionally recalculate them). That makes sense; branch_leaves is a cache, and if one cache is broken, it's likely others are. It took a noticable but not significant time to run 'recalc_branch_heads', but there's no reason not to include it in regenerate_caches. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Net sync with 0.47 server fails...
syncing with 0.47 server results on the client mtn.EXE: warning: protocol error while processing peer hostname: 'received network error: denied 'c64200903a4402fff7dcf6343d0290dfbecb5713' write permission for '*' excluding ''' doing a quick serch for 'monotone sync 0.47' comes up with http://osdir.com/ml/debian-bugs-dist/2010-03/msg06590.html I had to modify my server's monontonerc to return true for get_netsync_read_permitted and get_netsync_write_permitted... otherwise, even though the key is listed as if( identity == u...@host.com ) then return true end it doesn't allow the user read or write permission. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] get rev_id of merge
Stephen Leake stephen_le...@stephe-leake.org writes: Thomas Keller m...@thomaskeller.biz writes: Am 04.05.10 16:18, schrieb Stephen Leake: I'm trying to get the rev_id of a merge, in a Lua test. Can anyone tell me why this doesn't work? I based it on base_revision(). function merged_revision() local workrev = readfile(stderr) local extract = string.gsub(workrev, ^mtn: %[merged%] (%x*)$, %1) This will not work with multi-line string input, because ^ marks the very beginning and $ the very end of the string, not the line. But even if you remove these, you'll only process the replacement of the matched line, while you actually want to extract something. This should work better: local extract = string.match(workrev, mtn: %[merged%] (%x*)) That does work, and is clearer, but I don't understand the explanation. Why does base_revision work? I figured it out; there's a .* which matches everthing from the start of the string, and the desired string happens to be at the end of the file. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
