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
