[Monotone-devel] I don't know if this is a good idea or not
Inspired by the 0.37 mtn_automate and register_command hooks, I've written
what's become a fairly lengthy lua script, suitable for inclusion from a
monotonerc that provides rudimentary release management.
It adds two commands:
mtn release [version (M.m.s)] [revision] adds an x-revision cert to the
revision with the version number in it and outputs a changelog
mtn changelog [file] outputs a basic changelog based on the commit messages
in the current branch up to and including the last x-release certified
revision
The changelog can be trimmed with a changelog_ignore file - patterns in the
file will be eliminated from the output.
If nothing else, I've cemented my understanding of how certificates and
revisions interrelate, and there are a number of useful support functions in
the file that might be worth pulling out into a utility.lua later.
Judson
--
Your subnet is currently 169.254.0.0/16. You are likely to be eaten by a
grue.
function parse_certs(certs)
local certs_table = {}
for cert,space in string.gmatch(certs .. \n\n, (.-)(\n\n)) do
local cert_table = {}
cert = parse_basic_io(cert)
for i,name_value in pairs(cert) do
cert_table[name_value[name]] = name_value[values]
end
table.insert(certs_table, cert_table)
end
return certs_table
end
function trusted_certs(certs)
certs = parse_certs(certs)
local trusted_certs = {}
for _,cert in pairs(certs) do
name = cert[name][1]
if cert[trust][1] == trusted then
if not trusted_certs[name] then
trusted_certs[name] = cert[value]
else
for _,value in pairs(cert[value]) do
table.insert(trusted_certs[name], value)
end
end
end
end
return trusted_certs
end
function split_string(list, pattern)
local return_table = {}
for item in string.gmatch(list, pattern) do
table.insert(return_table,item)
end
return return_table
end
function table.reverse(list)
local reversed = {}
for _,item in pairs(list) do
table.insert(reversed, 1, item)
end
return reversed
end
function get_branch()
local result,branch = mtn_automate(get_option, branch)
return string.gsub(branch, %s*$, )
end
function get_head_revision(branch)
local result,head = mtn_automate(select, h: .. branch)
return string.gsub(head, %s*$, )
end
function get_release_revisions(branch)
local result,release_revs = mtn_automate(select, b: .. branch .. /c:x-release)
release_revs = split_string(release_revs, %s*(%S*)%s+)
result,release_revs = mtn_automate(toposort, unpack(release_revs))
release_revs = split_string(release_revs, %s*(%S*)%s+)
return release_revs
end
function extract_release_from(rev)
local result,certs = mtn_automate(certs, rev)
certs = trusted_certs(certs)
local release = certs[x-release][1]
local maj,min,sub = release:match((%d+)[.](%d+)[.](%d+))
return tonumber(maj),tonumber(min),tonumber(sub)
end
function mark_release(release_number, rev)
if not release_number then
local major, minor, sub
local rel_revs = get_release_revisions(get_branch())
if(not rel_revs or #rel_revs == 0) then
major, minor, sub = 0,0,0
else
major, minor, sub = extract_release_from(rel_revs[#rel_revs])
end
sub = sub + 1
release_number = string.format(%d.%d.%d,major,minor,sub)
print(string.format(Automatically generating release number %s, release_number))
end
local result,branch
if not rev then
rev = get_head_revision(get_branch())
end
mtn_automate(cert, rev, x-release, release_number)
mtn_automate(cert, rev, changelog, Marked release .. release_number)
end
function output_changelog(out_path)
local result, branch, head, release_revs, changelog_revs
local certs, out, skip_pattern_list
branch = get_branch()
release_revs = get_release_revisions(branch)
head = get_head_revision(branch)
result,changelog_revs = mtn_automate(select, b: .. branch)
if #release_revs 0 then
result, changelog_revs = mtn_automate(ancestry_difference, head, unpack(release_revs))
end
changelog_revs = split_string(changelog_revs, %s*(%S*)%s+)
result,changelog_revs = mtn_automate(toposort, unpack(changelog_revs))
changelog_revs2 = release_revs[#release_revs] .. .. changelog_revs ..
changelog_revs = table.reverse(split_string(changelog_revs2, %s*(%S*)%s+))
if out_path == nil then
out = io.stdout
else
out,result = io.open(out_path, w)
if(out == nil) then
print(Can't open .. out_path)
return
end
end
local skip_pattern_list = {}
local skip_patterns = io.open(get_confdir() .. /changelog_ignore, r)
if skip_patterns then
for pattern in skip_patterns:lines() do
table.insert(skip_pattern_list, pattern)
end
end
skip_patterns:close()
for _,rev in pairs(changelog_revs) do
result, certs = mtn_automate(certs, rev)
certs = parse_certs(certs)
for _,cert in pairs(certs) do
if cert[name] == changelog then
local value
value = table.concat(cert[value], \n)
value =
Re: [Monotone-devel] Patches and questions to various automate commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller schrieb: automate keys: -- A small little glich I encountered just recently: A running mtn instances won't notice if a key has been dropped from the keystore because it reads the local keystore only once (maybe_read_key_dir() in key_store.cc). Now, I _think_ the whole key_store caching thing is a bad idea at all because there is at least one other command I know (automate cert) which now runs over stdio and needs an up-to-date key list as well. However, I have no idea if its really a good idea to completly remove the keystore cache as I did in keystore.patch. Nevermind that one - this was a too quick shot. Not only that the patch is incomplete, if I fix that the error still pops up when using mtn over stdio. I need to investigate this further... 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 iD8DBQFHXl5Eaf7NlBYNEJIRAiagAJ0ddswm8mOB7qX0V5SP1M0Sil7+aACgvcks gi3UDIhYRXAmBYulcUcJhL8= =UDa/ -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] As you probably noticed, the release got delayed...
On Dec 10, 2007 2:07 AM, Richard Levitte [EMAIL PROTECTED] wrote: Hi, Some of you must have noticed that I didn't keep my own schedule. The reasons are many, and one of them is that I wanted to give the currently latest Debian package (0.37-4) time to trickle down into the [testing] distribution. I'll take a look at available information later today and will decide on a release date accordingly. Looks like it made it in today. When you do do the release, please make sure the commit log for 76d4b5766373d8c550acd922311824d28ddfa7cb gets copied into debian/changelog. (I didn't put it there myself because it causes trouble if we have an incomplete debian/changelog stanza at the top of the file... better ideas welcome.) It's mostly trivial but there's a bugfix too. thanks, zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] I can haz mtn:// plz?
An it-would-be-nice: if mtn pull/push/sync mtn://server/branchpattern fired up the netsync protocol. if only so one could get a bit of mileage out of Vcs-Mtn: in Debian package control files, which are currently only good for ssh transport. I think. zw -- should not be awake right now ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: I don't know if this is a good idea or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Judson Lester schreef: Inspired by the 0.37 mtn_automate and register_command hooks, I've written what's become a fairly lengthy lua script, suitable for inclusion from a monotonerc that provides rudimentary release management. It adds two commands: mtn release [version (M.m.s)] [revision] adds an x-revision cert to the revision with the version number in it and outputs a changelog mtn changelog [file] outputs a basic changelog based on the commit messages in the current branch up to and including the last x-release certified revision The changelog can be trimmed with a changelog_ignore file - patterns in the file will be eliminated from the output. If nothing else, I've cemented my understanding of how certificates and revisions interrelate, and there are a number of useful support functions in the file that might be worth pulling out into a utility.lua later. I get: Powerbook-2:org.openembedded.dev.avr32 koen$ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:117: attempt to concatenate field '?' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. Powerbook-2:org.openembedded.dev.avr32 koen$ mtn --version monotone 0.37 (base revision: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec) The error is from this portion (line numbers added): 115 changelog_revs = split_string(changelog_revs, %s*(%S*)%s+) 116 result,changelog_revs = mtn_automate(toposort, unpack(changelog_revs)) 117 changelog_revs2 = release_revs[#release_revs] .. .. changelog_revs .. 118 changelog_revs = table.reverse(split_string(changelog_revs2, %s*(%S*)%s+)) any idea what is causing this error? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHXmjuMkyGM64RGpERAhydAJ0Ypk9/xHxZwjOH06E/gdYKYXxQaQCgiuqj egcRPGP847sAgDGX2LXtjlo= =jhAI -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: I don't know if this is a good idea or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Koen Kooi schrieb: I get: Powerbook-2:org.openembedded.dev.avr32 koen$ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:117: attempt to concatenate field '?' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. Powerbook-2:org.openembedded.dev.avr32 koen$ mtn --version monotone 0.37 (base revision: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec) The error is from this portion (line numbers added): 115 changelog_revs = split_string(changelog_revs, %s*(%S*)%s+) 116 result,changelog_revs = mtn_automate(toposort, unpack(changelog_revs)) 117 changelog_revs2 = release_revs[#release_revs] .. .. changelog_revs .. 118 changelog_revs = table.reverse(split_string(changelog_revs2, %s*(%S*)%s+)) any idea what is causing this error? There is no tagged release revision yet, therefor release_revs[#release_revs] is a Nil value. I emailed him about this (and other stuff) already. Try to `mtn release RELEASE_NUMBER REV_ID` before. 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 iD8DBQFHXmpbaf7NlBYNEJIRAvK4AKDOpuwbSJu+jUrzxPp4Rfcw7ALUpQCdGvSS djPbJf0RiiTT4fQWHo2qQTI= =LAhX -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: I don't know if this is a good idea or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller schreef: Koen Kooi schrieb: I get: Powerbook-2:org.openembedded.dev.avr32 koen$ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:117: attempt to concatenate field '?' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. Powerbook-2:org.openembedded.dev.avr32 koen$ mtn --version monotone 0.37 (base revision: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec) The error is from this portion (line numbers added): 115 changelog_revs = split_string(changelog_revs, %s*(%S*)%s+) 116 result,changelog_revs = mtn_automate(toposort, unpack(changelog_revs)) 117 changelog_revs2 = release_revs[#release_revs] .. .. changelog_revs .. 118 changelog_revs = table.reverse(split_string(changelog_revs2, %s*(%S*)%s+)) any idea what is causing this error? There is no tagged release revision yet, therefor release_revs[#release_revs] is a Nil value. I emailed him about this (and other stuff) already. Try to `mtn release RELEASE_NUMBER REV_ID` before. Ok, setting that to somewhere last friday: $ mtn release 0.0.0 0e4a2bbb7147a46977d9c8085b4fd469d11ab2a2 $ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:137: attempt to index local 'skip_patterns' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. the MAINTAINERS file didn't have a cset in the 0e4a2bbb7147a46977d9c8085b4fd469d11ab2a2 now period, could that be a reason? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHXmxaMkyGM64RGpERAvwRAJ91/fRbRDvSvr+5sH37dnsPtiBMVwCeLJji y8Wy1BtSqrHKGl52ijvFPLc= =SRLU -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: I don't know if this is a good idea or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Koen Kooi schrieb: Thomas Keller schreef: Koen Kooi schrieb: I get: Powerbook-2:org.openembedded.dev.avr32 koen$ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:117: attempt to concatenate field '?' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. Powerbook-2:org.openembedded.dev.avr32 koen$ mtn --version monotone 0.37 (base revision: c21eefc002b8f9c430e9f4cc16c4af7b852f54ec) The error is from this portion (line numbers added): 115 changelog_revs = split_string(changelog_revs, %s*(%S*)%s+) 116 result,changelog_revs = mtn_automate(toposort, unpack(changelog_revs)) 117 changelog_revs2 = release_revs[#release_revs] .. .. changelog_revs .. 118 changelog_revs = table.reverse(split_string(changelog_revs2, %s*(%S*)%s+)) any idea what is causing this error? There is no tagged release revision yet, therefor release_revs[#release_revs] is a Nil value. I emailed him about this (and other stuff) already. Try to `mtn release RELEASE_NUMBER REV_ID` before. Ok, setting that to somewhere last friday: $ mtn release 0.0.0 0e4a2bbb7147a46977d9c8085b4fd469d11ab2a2 $ mtn changelog MAINTAINERS mtn: warning: _MTN/monotonerc:137: attempt to index local 'skip_patterns' (a nil value) mtn: error: Call to user command changelog (lua command: output_changelog) failed. the MAINTAINERS file didn't have a cset in the 0e4a2bbb7147a46977d9c8085b4fd469d11ab2a2 now period, could that be a reason? No, this error comes from the fact you probably have no changelog_ignore file yet and the code here local skip_patterns = io.open(get_confdir() .. /changelog_ignore, r) if skip_patterns then for pattern in skip_patterns:lines() do table.insert(skip_pattern_list, pattern) end end skip_patterns:close() should actually read like this in this case: local skip_patterns = io.open(get_confdir() .. /changelog_ignore, r) if skip_patterns then for pattern in skip_patterns:lines() do table.insert(skip_pattern_list, pattern) end skip_patterns:close() end Still, even after I fixed that I didn't manage to output the log messages, obviously there are revisions for me which are crawled. Haven't looked further into it though, now you're on your own ;) 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 iD8DBQFHXm2Xaf7NlBYNEJIRAssxAJ45YKA2Fh+pjFvTFxtzeREFVCc1ZQCg7hgO Ds0WSFT2gJZ4fDOHZ7x5eGc= =0/BR -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] As you probably noticed, the release got delayed...
In message [EMAIL PROTECTED] on Tue, 11 Dec 2007 02:00:42 -0800, Zack Weinberg [EMAIL PROTECTED] said: zackw On Dec 10, 2007 2:07 AM, Richard Levitte [EMAIL PROTECTED] wrote: zackw Hi, zackw zackw Some of you must have noticed that I didn't keep my own schedule. The zackw reasons are many, and one of them is that I wanted to give the zackw currently latest Debian package (0.37-4) time to trickle down into the zackw [testing] distribution. I'll take a look at available information zackw later today and will decide on a release date accordingly. zackw zackw Looks like it made it in today. Verified, I just saw it on my testing machine. Woohoo! OK, that means I'll release tonight or tomorrow morning. Guys, please double-check the NEWS entries for 0.38! zackw When you do do the release, please make sure the commit log for zackw 76d4b5766373d8c550acd922311824d28ddfa7cb gets copied into zackw debian/changelog. (I didn't put it there myself because it zackw causes trouble if we have an incomplete debian/changelog stanza zackw at the top of the file... better ideas welcome.) It's mostly zackw trivial but there's a bugfix too. Can't you do what I did in the .debian-diff branch, an entry that says UNRELEASED? Anyway, I'll add it now in my local repo... 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] hang on Win32/MinGW with sync file:
At 2007-12-09T16:32:42-0500, Stephen Leake wrote: mtn: fatal: std::runtime_error: network error: select(2): An operation was attempted on something that is not a socket. (10038) Okay so far, you'd expect to see this when the stdio handles are not sockets. The same occurs when 'mtn --stdio' is spawned with a socket as stdio, as you can see in tester.log. So... we need to work out why this is happening, because it should work. I haven't had time to look over your changes in any depth yet, but I will have some time in the weekend, so if you're still stuck on this I'll take a crack at it as well. So I think we are back to the fundamental problem; how do we do non-blocking IO on Win32 stdio? I have a working standalone proof of concept for this approach already, so I know we can make it work with monotone. Cheers, -mjg -- Matthew Gregan |/ /|[EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] 'make' error when installing monotone-0.31
Hello, I am a new developer and trying to learn how to create dreambox images. I have successfully created a DM500 image and am looking to progress to DM600-PVR images. For this, I need to install monotone. :) I am following your tutorial here... http://monotone.ca/INSTALL At no.3, 3. building monotone * type make. this should produce a mtn binary in your current directory. if not, please send a build log to monotone-devel@nongnu.org with a description of the failure. ...I am getting an error. vocab.hh:126: error: using typedef-name ‘boost::filesystem::path’ after ‘class’ /usr/include/boost/filesystem/path.hpp:43: error: ‘boost::filesystem::path’ has a previous declaration here make[2]: *** [mtn-paths.o] Error 1 make[2]: Leaving directory `/home/devilfish/monotone/monotone-0.31' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/devilfish/monotone/monotone-0.31' make: *** [all] Error 2 [EMAIL PROTECTED]:~/monotone/monotone-0.31$ Can you please assist me in correcting this? Any help you offer will be greatly appreciated. Regards Glen (aka Devilfish) - http://www.digitalworldz.co.uk/ If you can hack it - you should! _ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 'make' error when installing monotone-0.31
Glen Buchanan schrieb: vocab.hh:126: error: using typedef-name ‘boost::filesystem::path’ after ‘class’ /usr/include/boost/filesystem/path.hpp:43: error: ‘boost::filesystem::path’ has a previous declaration here make[2]: *** [mtn-paths.o] Error 1 make[2]: Leaving directory `/home/devilfish/monotone/monotone-0.31' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/devilfish/monotone/monotone-0.31' make: *** [all] Error 2 [EMAIL PROTECTED]:~/monotone/monotone-0.31$ Can you please assist me in correcting this? Any help you offer will be greatly appreciated. While I can't help you on this specific issue, may I ask why you're trying to build this old version instead of 0.37? Maybe your issue was already fixed in one of the newer versions? Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Für Freiheit und gegen staatliche Überwachungsmaßnahmen: http://leipzig.vorratsdatenspeicherung.de 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] conflict messages
Nathaniel Smith wrote: On Mon, Dec 10, 2007 at 09:02:54PM -0700, Derek Scherger wrote: I really don't expect that this change is going to cause any major problems but a few fetching non-existent entry from children type of errors would not really surprise me. There are a lot of node ids being looked up in several different rosters and while I tried hard to be thorough it's very possible that I've missed something. Maybe you could test it? :-) There is a reasonably comprehensive test in tests/conflict_messages at the moment that generates each of the various conflict types and runs update, show_conflicts, merge, pluck and merge_into_workspace against them to ensure these all report things correctly. You do make me realize that it doesn't yet run explicit_merge or propagate on each of these cases and doing so should be simple enough so I'll add that. (Depending on what interface it uses, you may just be able to plug it into the giant merge unit tests -- they should be creating every possible conflict situation.) At a glance it doesn't look like it will fit nicely into the existing merge unit tests. None of these set up a parent roster which is used various places to get old names and such. Access to the parent roster comes from the get_ancestral_roster functions in content_merge_workspace_adaptor and content_merge_database_adaptor and we would need to set the tests up with some other content_merge_testing_adaptor. To some degree it seems like we'd be testing the test code rather than the real code and we would still be missing variations of the various merge commands. Looking at the unit tests I think I have all of the simple_structural_conflicts cases covered in the existing lua test and maybe I'll just try and add the complex_structural_conflicts cases to that. Even with this it still won't surprise me if we hit a fetching non-existent node from children problem or two. ;) Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I can haz mtn:// plz?
On Tue, Dec 11, 2007 at 02:07:40AM -0800, Zack Weinberg wrote: An it-would-be-nice: if mtn pull/push/sync mtn://server/branchpattern fired up the netsync protocol. if only so one could get a bit of mileage out of Vcs-Mtn: in Debian package control files, which are currently only good for ssh transport. I think. +1 -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
