Re: [Monotone-devel] nvm.fast-export
On Thu, Mar 5, 2009 at 6:44 PM, Derek Scherger wrote: > > On Thu, Mar 5, 2009 at 2:32 AM, Felipe Contreras > wrote: >> >> I'm about at 90% of verifying the exactness compared to my method. I >> think I'll be able to complete that before the weekend, but I don't >> think I'll find any issue. >> >> Great job! > > Ok good. I'm not in any real rush so maybe I'll wait until you finish. Verified. Both methods generate exactly the same sha1's :) -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone 0.43dev build error, paths.hh missing
Hi, It seems that merge_content.hh is missing #include "paths.hh". When compiling rev d24b59732a5b3293592457cba013c8f8b716a875, I get error: if g++ -I. -I. -I. -I/usr/local/include -I/home/tkoskine/libraries/bo tan-18/include -I/usr/local//include -I/usr/local/include -g -I/usr/local/i nclude -g -O2 -Wall -W -Wno-unused -MT merge_roster.o -MD -MP -MF "$depbase.Tpo " -c -o merge_roster.o merge_roster.cc; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi In file included from merge_roster.hh:18, from merge_roster.cc:12: /usr/include/g++/bits/stl_pair.h: In instantiation of `std::pair': /usr/include/g++/bits/stl_tree.h:123: instantiated from `std::_Rb_tree_node >' /usr/include/g++/bits/stl_alloc.h:242: instantiated from `static void std::__s imple_alloc<_Tp, _Alloc>::deallocate(_Tp*, long unsigned int) [with _Tp = std::_ Rb_tree_node >, _Alloc = std::__default_allo c_template]' /usr/include/g++/bits/stl_tree.h:567: instantiated from `void std::_Rb_tree_al loc_base<_Tp, _Alloc, true>::_M_put_node(std::_Rb_tree_node<_Val>*) [with _Tp = std::pair, _Alloc = std::allocator >]' /usr/include/g++/bits/stl_tree.h:580: instantiated from `std::_Rb_tree_base<_T p, _Alloc>::~_Rb_tree_base() [with _Tp = std::pair, _A lloc = std::allocator >]' /usr/include/g++/bits/stl_tree.h:748: instantiated from `std::_Rb_tree<_Key, _ Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with _Key = file_id, _Val = st d::pair, _KeyOfValue = std::_Select1st >, _Compare = std::less, _Alloc = std::allocator >]' merge_content.hh:107: instantiated from here /usr/include/g++/bits/stl_pair.h:74: error: `std::pair<_T1, _T2>::second' has incomplete type rev_types.hh:53: error: forward declaration of `struct file_path' gmake[1]: *** [merge_roster.o] Error 1 gmake[1]: Leaving directory `/home/tkoskine/work/monotone/trunk' gmake: *** [all] Error 2 Following diff fixes build for me: # # old_revision [d24b59732a5b3293592457cba013c8f8b716a875] # # patch "merge_content.hh" # from [119dac7660310c581b280923d4c5000266f0e54f] #to [f686979a4a2f6af3912880b91d8c9fea3be2db06] # --- merge_content.hh119dac7660310c581b280923d4c5000266f0e54f +++ merge_content.hhf686979a4a2f6af3912880b91d8c9fea3be2db06 @@ -13,6 +13,7 @@ #include "vocab.hh" #include "rev_types.hh" +#include "paths.hh" class database; class lua_hooks; -- Tero Koskinen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Issues with mtn commit and the latest net.venge.monotone head
Hi, "mtn commit" seems to be broken in revision d24b59732a5b3293592457cba013c8f8b716a875. I found out two problems Problem 1) When doing "mtn commit" I get: $ mtn ci mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven' mtn.real: warning: [string ""]:314: bad argument #1 to 'find' (string expected, got nil) mtn.real: misuse: edit of log message failed $ Setting EDITOR to "vi" (or something else helps): $ echo $EDITOR $ export EDITOR=vi $ mtn commit mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven' mtn.real: committed revision 40a7d624e7f9f798ce2d6edac39b39712ce9fbdd $ The problem was gone when I updated to revision 04766db8e363880fd1d50692d793661d9f4fdcf4. (A newer revision might also work, I didn't iterate through every rev.) Problem 2) When doing "mtn commit -m 'long message'" I get unknown path errors: $ mtn commit -m 'Increase version to 1.7' mtn.real: warning: restriction includes unknown path '1.7' mtn.real: warning: restriction includes unknown path 'to' mtn.real: warning: restriction includes unknown path 'version' mtn.real: misuse: 3 unknown paths $ In other words, the text after the first word is interpreted as paths. Update to rev 04766db8e363880fd1d50692d793661d9f4fdcf4 didn't solve this, but in release 0.42 '-m' option works as expected. -- Tero Koskinen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Issues with mtn commit and the latest net.venge.monotone head
On Fri, 6 Mar 2009 23:10:05 +0200 Tero Koskinen wrote: > Hi, > > "mtn commit" seems to be broken in revision > d24b59732a5b3293592457cba013c8f8b716a875. Oh, and I am using OpenBSD 4.5/i386, g++ 3.3.5, boost 1.34, and botan 1.8.1 if that matters. $ mtn version --full monotone 0.43dev (base revision: 04766db8e363880fd1d50692d793661d9f4fdcf4) Running on : OpenBSD 4.5 GENERIC#1685 i386 C++ compiler: Unknown ISO C++ Compiler C++ standard library: Unknown ISO standard library Boost version : 1_34_1 SQLite version : 3.6.10 (compiled against 3.6.10) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.1 (compiled against 1.8.1) Changes since base revision: format_version "1" new_manifest [a5e63e06bd20f5092ac96e98d7dbef1c6befc140] old_revision [04766db8e363880fd1d50692d793661d9f4fdcf4] patch "merge_content.hh" from [c3dc50ac9bad4488b4583c84551f3c6302763a64] to [186e799f5cd9787817b23672daccb03a7f380a95] patch "std_hooks.lua" from [47f92f3269c99464106e72b9f3839027c3eacce1] to [1f0c51a34f82a4c686e50ca0faa01f22f328065f] -- Tero Koskinen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] automate get_current_revision failing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! In f62181ae.. someone made "mtn automate get_current_revision" fail in case the workspace is clean, and the revision is trivial (empty changeset). I don't see why this should fail, and furthermore, it breaks the logic that makes "mtn revision --full" display changes made against the base revision. So, I'd like to partially revert that (see patched attached). Any objections? - - Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmxsbcACgkQm/6MhNYca5jodgCggs5JkIahd2/C66oLXC/d5QgA sDoAn32ZHxIB2swDfYHeUFEx7iGshamO =zV9Z -END PGP SIGNATURE- # # old_revision [d24b59732a5b3293592457cba013c8f8b716a875] # # patch "automate.cc" # from [63b44f3c2366f52a040cc8d0029ffc1d896740d9] #to [4a5ef4b00f72c0c766b65bcf4d26fce3c662cbfc] # # patch "monotone.texi" # from [50c10e49ae961d0b36374f02b09b5af2fab9cb00] #to [d562dab57e07e0822e54af0b40dea69881c085c5] # # patch "tests/automate_get_current_revision/__driver__.lua" # from [a56d2598ca7be71521f38b0a577baa92fbf55022] #to [febb7bc6adea00e46e2f0e932ec3f939badab4a2] # --- automate.cc 63b44f3c2366f52a040cc8d0029ffc1d896740d9 +++ automate.cc 4a5ef4b00f72c0c766b65bcf4d26fce3c662cbfc @@ -1260,8 +1260,7 @@ CMD_AUTOMATE(get_revision, N_("REVID"), // Added in: 7.0 // Purpose: Outputs (an optionally restricted) revision based on // changes in the current workspace -// Error conditions: If there are no changes in the current workspace or the -// restriction is invalid or has no recorded changes, prints an error message +// Error conditions: If the restriction is invalid, prints an error message // to stderr and exits with status 1. A workspace is required. CMD_AUTOMATE(get_current_revision, N_("[PATHS ...]"), N_("Shows change information for a workspace"), @@ -1293,7 +1292,6 @@ CMD_AUTOMATE(get_current_revision, N_("[ make_restricted_revision(old_rosters, new_roster, mask, rev, excluded, join_words(execid)); rev.check_sane(); - E(rev.is_nontrivial(), origin::user, F("no changes to commit")); calculate_ident(rev, ident); write_revision(rev, dat); --- monotone.texi 50c10e49ae961d0b36374f02b09b5af2fab9cb00 +++ monotone.texi d562dab57e07e0822e54af0b40dea69881c085c5 @@ -7716,9 +7716,8 @@ @section Automation @item Error conditions: -If the command is executed outside of a workspace, there are no changes in the -current workspace or the restriction is invalid or has no recorded changes, -prints an error message to stderr and exits with status 1. +If the command is executed outside of a workspace, or the restriction is +invalid, prints an error message to stderr and exits with status 1. @end table --- tests/automate_get_current_revision/__driver__.lua a56d2598ca7be71521f38b0a577baa92fbf55022 +++ tests/automate_get_current_revision/__driver__.lua febb7bc6adea00e46e2f0e932ec3f939badab4a2 @@ -6,8 +6,7 @@ check(mtn("commit", "--date=2005-05-21T1 "--branch=testbranch", "--message=blah-blah"), 0, false, false) -- ensure clear workspace fails wih error -check(mtn("automate", "get_current_revision"), 1, true, false) -check(fsize("stdout") == 0) +check(mtn("automate", "get_current_revision"), 0, true, false) addfile("foox", "blah\n") addfile("barx", "blah2\n") get_current_revision.patch.sig Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.fast-export
On Fri, Mar 6, 2009 at 1:54 AM, Felipe Contreras wrote: > > > Ok good. I'm not in any real rush so maybe I'll wait until you finish. > > Verified. Both methods generate exactly the same sha1's :) > Excellent. That makes me feel better about merging it to mainline in time for 0.43 which I'll do sometime later on this weekend. Thanks for the effort. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.43dev build error, paths.hh missing
On Fri, Mar 6, 2009 at 1:15 PM, Tero Koskinen wrote: > Hi, > > It seems that merge_content.hh is missing #include "paths.hh". This is quite likely because I moved content_merge_workspace_adaptor to merge_content.{cc,hh} from work.{cc,hh} in dbf38fd6d5265df467a88a468d110bcc039c2367. Just to confirm, can you try building add275e5fdb0824361d4a2fa15049281e7ada52e please? I'm not sure why I don't see the problem here though, gcc 4.1.2 seems perfectly happy on a fresh checkout? When compiling rev d24b59732a5b3293592457cba013c8f8b716a875, I get error: >if g++ -I. -I. -I. -I/usr/local/include > -I/home/tkoskine/libraries/bo > tan-18/include -I/usr/local//include -I/usr/local/include -g > -I/usr/local/i > nclude -g -O2 -Wall -W -Wno-unused -MT merge_roster.o -MD -MP -MF > "$depbase.Tpo > " -c -o merge_roster.o merge_roster.cc; \ >then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; > exit > 1; fi > In file included from merge_roster.hh:18, > from merge_roster.cc:12: > Any chance that 'fi' is not closing the preceeding if but was a 'file...' something or other line that was chopped of and might have a bit more info? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.43dev build error, paths.hh missing
On Fri, Mar 06, 2009 at 08:19:39PM -0700, Derek Scherger wrote: > I'm not sure why I don't see the problem here though, gcc 4.1.2 seems > perfectly happy on a fresh checkout? I built/tested d24b59732a5b3293592457cba013c8f8b716a875 from a clean checkout with gcc 4.3.3 on x86-64/Linux and have been using it as my installed mtn binary for about 8 hours now. No problems. monotone 0.43dev (base revision: d24b59732a5b3293592457cba013c8f8b716a875) Running on : Linux 2.6.26.8-3 #1 SMP Mon Nov 17 09:51:24 EST 2008 x86_64 C++ compiler: GNU C++ version 4.3.3 C++ standard library: GNU libstdc++ version 20090124 Boost version : 1_35 SQLite version : 3.6.6.2 (compiled against 3.6.6.2) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.0 (compiled against 1.8.0) Changes since base revision: unknown -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Issues with mtn commit and the latest net.venge.monotone head
On Fri, Mar 6, 2009 at 2:10 PM, Tero Koskinen wrote: > Hi, > > "mtn commit" seems to be broken in revision > d24b59732a5b3293592457cba013c8f8b716a875. > > I found out two problems > > Problem 1) > > When doing "mtn commit" I get: > $ mtn ci > mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven' > mtn.real: warning: [string ""]:314: bad argument #1 to 'find' > (string expected, got nil) > mtn.real: misuse: edit of log message failed > $ > Downthread your monotone version reports that std_hooks.lua is patched, any chance there's a stray change in there causing the problem? > Setting EDITOR to "vi" (or something else helps): > $ echo $EDITOR > > $ export EDITOR=vi > $ mtn commit > mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven' > mtn.real: committed revision 40a7d624e7f9f798ce2d6edac39b39712ce9fbdd > $ > > The problem was gone when I updated to revision > 04766db8e363880fd1d50692d793661d9f4fdcf4. (A newer revision might also > work, I didn't iterate through every rev.) > > Problem 2) > > When doing "mtn commit -m 'long message'" I get unknown path errors: > $ mtn commit -m 'Increase version to 1.7' > mtn.real: warning: restriction includes unknown path '1.7' > mtn.real: warning: restriction includes unknown path 'to' > mtn.real: warning: restriction includes unknown path 'version' > mtn.real: misuse: 3 unknown paths > $ This looks like a shell problem. I don't know how monotone can cause a quoted string to become separated. Is "mtn" a script that doesn't have the proper "$@" or whatever with required quotes to represent arguments? I'm wondering about a script because you say "mtn" and it reports "mtn.real" ? Also, what shell are you running? Looking at it again I wonder if your first problem has the same cause? In other words, the text after the first word is interpreted as paths. > Update to rev 04766db8e363880fd1d50692d793661d9f4fdcf4 didn't solve > this, but in release 0.42 '-m' option works as expected. Is that one running through the same script if there is one? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Issues with mtn commit and the latest net.venge.monotone head
On Fri, 6 Mar 2009 20:30:59 -0700 Derek Scherger wrote: > On Fri, Mar 6, 2009 at 2:10 PM, Tero Koskinen wrote: > > > Hi, > > > > "mtn commit" seems to be broken in revision > > d24b59732a5b3293592457cba013c8f8b716a875. > > > > I found out two problems > > > > Problem 1) > > > > When doing "mtn commit" I get: > > $ mtn ci > > mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven' > > mtn.real: warning: [string ""]:314: bad argument #1 to 'find' > > (string expected, got nil) > > mtn.real: misuse: edit of log message failed > > $ > > > > Downthread your monotone version reports that std_hooks.lua is patched, any > chance there's a stray change in there causing the problem? It shouldn't, difference is following: # # old_revision [04766db8e363880fd1d50692d793661d9f4fdcf4] # # patch "merge_content.hh" # from [c3dc50ac9bad4488b4583c84551f3c6302763a64] #to [186e799f5cd9787817b23672daccb03a7f380a95] # # patch "std_hooks.lua" # from [47f92f3269c99464106e72b9f3839027c3eacce1] #to [1f0c51a34f82a4c686e50ca0faa01f22f328065f] # --- merge_content.hhc3dc50ac9bad4488b4583c84551f3c6302763a64 +++ merge_content.hh186e799f5cd9787817b23672daccb03a7f380a95 @@ -13,6 +13,7 @@ #include "vocab.hh" #include "rev_types.hh" +#include "paths.hh" class database; class lua_hooks; --- std_hooks.lua 47f92f3269c99464106e72b9f3839027c3eacce1 +++ std_hooks.lua 1f0c51a34f82a4c686e50ca0faa01f22f328065f @@ -439,11 +439,19 @@ mergers.tortoise = { wanted = function () return true end } +function get_gnu_diff() + return "gdiff" +end + +function get_gnu_diff3() + return "gdiff3" +end + mergers.vim = { cmd = function (tbl) function execute_diff3(mine, yours, out) local diff3_args = { -"diff3", +get_gnu_diff3(), "--merge", "--easy-only", } @@ -498,7 +506,7 @@ mergers.vim = { end , available = function () - return program_exists_in_path("diff3") and + return program_exists_in_path(get_gnu_diff3()) and (program_exists_in_path("vim") or program_exists_in_path("gvim")) end , > > Problem 2) > > > > When doing "mtn commit -m 'long message'" I get unknown path errors: > > $ mtn commit -m 'Increase version to 1.7' > > mtn.real: warning: restriction includes unknown path '1.7' > > mtn.real: warning: restriction includes unknown path 'to' > > mtn.real: warning: restriction includes unknown path 'version' > > mtn.real: misuse: 3 unknown paths > > $ > > > This looks like a shell problem. I don't know how monotone can cause a > quoted string to become separated. Is "mtn" a script that doesn't have the > proper "$@" or whatever with required quotes to represent arguments? I'm > wondering about a script because you say "mtn" and it reports "mtn.real" ? > Also, what shell are you running? > > Looking at it again I wonder if your first problem has the same cause? Oops, this was my own fault. My 'mtn' is a shell wrapper around real mtn command to get library paths right. I wasn't using double quotes around $...@. Following script solved the -m option problem: #!/bin/sh LD_LIBRARY_PATH=$HOME/libraries/botan-18/lib mtn.real "$@" # end of script -- Tero Koskinen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.43dev build error, paths.hh missing
On Fri, 6 Mar 2009 20:19:39 -0700 Derek Scherger wrote: > On Fri, Mar 6, 2009 at 1:15 PM, Tero Koskinen wrote: > > > Hi, > > > > It seems that merge_content.hh is missing #include "paths.hh". > > > This is quite likely because I moved content_merge_workspace_adaptor to > merge_content.{cc,hh} from work.{cc,hh} in > dbf38fd6d5265df467a88a468d110bcc039c2367. Just to confirm, can you try > building add275e5fdb0824361d4a2fa15049281e7ada52e please? Building add275... failed also in the same place, complete log is at http://iki.fi/tero.koskinen/monotone/monotone-build-radd275e5fdb082.txt > I'm not sure why I don't see the problem here though, gcc 4.1.2 seems > perfectly happy on a fresh checkout? I am using gcc 3.3.5 on OpenBSD. It might have some bugs which are fixed in gcc 4 series. (gcc 3.3.5 is the default system compiler, I use it because all C and C++ libraries are compiled with it.) -- Tero Koskinen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel