possible bug
Possible bug: mtn: warning: expected file 'Melinda/src/delete', but it is a directory. mtn: fatal: error: src/work.cc:1896: I(ident_existing_file(name, fid)) mtn: This is almost certainly a bug in monotone. mtn: Please report this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to 'https://code.monotone.ca/p/monotone/issues/'. mtn: wrote debugging log to /home/hendrik/write/Melinda/_MTN/debug mtn: if reporting a bug, please include this file Version: monotone 1.1 (base revision: 81fa9664405655b13bde971bddd802de25096073) Running on : Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 C++ compiler: GNU C++ version 5.4.0 20160609 C++ standard library: GNU libstdc++ version 20160609 Boost version : 1_58 SQLite version : 3.34.1 (compiled against 3.13.0) Lua version : Lua 5.2 PCRE version: 8.39 2016-06-14 (compiled against 8.38) Botan version : 1.10.16 (compiled against 1.10.12) Changes since base revision: format_version "1" new_manifest [3f49ef95c9afe8094b075119cad01839c44885e3] old_revision [81fa9664405655b13bde971bddd802de25096073] Generated from data cached in the distribution; further changes may have been made. I was trying to do a routing commit, after doing edits and moving a few obsolete files into the 'delete' directory. Evidently I did something quite wrong, because monotone now thinks that delete is a file. I *might* have done something like mtn mv Makefile delete/ to move the obsolete file called Makefile into the 'delete' directory, which I use as a kind of trash can, just in case. But I really don't remember what I did any more. I do remember making mistakes and haveing monotone quite reasonably call me out. Until finally it thought it might have a bug. I'll find a way to go on -- probably getting rid of the delete directory, creating a file called delete, and then mtn dropping it. -- hendrik
Re: [Monotone-devel] Possible bug in `mtn log`?
Am 07.07.2010 00:54, schrieb Thomas Keller: Am 06.07.10 23:10, schrieb Thomas Keller: Am 06.07.10 19:15, schrieb Marcin W. Dąbrowski: Hi. Today I hit something weird, when trying to see the history of one of the files in my repository - `mtn log filename.ext` is showing logs for other files than 'filename.ext'. I tried to find minimal case, and running the sequence you can see presented below hits the bug - or to say this in other words — it shows not exactly the information I'd like to see. [snip] I see two changelogs printed. I don't know why I see the changelog for example.txt, nor why the order is chronological (normally it should be reverse chronology - usually it is). So - is this by design (no, really?), or a bug? I think this is a fall-out of the new restrictions code which landed in 0.48 (try out 0.47 and you see the expected behaviour). We now implicitely include all parents of a node in a restriction and as such, if you log sec/second.txt, changes for sec and (the root node) are also logged. I'll try out a fix and switch the restriction handling mode to what we use also for 'revert', i.e. no implicit includes. I committed a temporary fix in branch net.venge.monotone.restriction-fixes, but this is not ready for mainline yet, because it breaks one test, namely log_--diffs. This issue has been resolved and the fix (b0327e6eb8d1617b46a335111ef1677ad23287ae) landed in mainline. 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
[Monotone-devel] Possible bug in `mtn log`?
Hi. Today I hit something weird, when trying to see the history of one of the files in my repository - `mtn log filename.ext` is showing logs for other files than 'filename.ext'. I tried to find minimal case, and running the sequence you can see presented below hits the bug - or to say this in other words — it shows not exactly the information I'd like to see. #v+ mtn -d mtn.mtn db init mtn -d mtn.mtn setup . -b mtn.bug.log echo x example.txt mtn add example.txt mtn ci -m Added new file. mkdir sec cd sec mtn -d ../mtn.mtn setup . -b mtn.bug.sec echo y second.txt mtn add second.txt mtn ci -m Added new file, second branch. -b mtn.bug.sec cd .. mtn up -r h: -b mtn.bug.log rm -rf sec mtn merge_into_dir --update -m merge_into_dir src mtn.bug.sec mtn.bug.log sec cd sec mtn log --no-merges second.txt #v- I see two changelogs printed. I don't know why I see the changelog for example.txt, nor why the order is chronological (normally it should be reverse chronology - usually it is). So - is this by design (no, really?), or a bug? PS: mtn version --full gives monotone 0.48 (base revision: 844268c137aaa783aa800a9c16ae61edda80ecea) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) Sincerely, -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Possible bug in `mtn log`?
Am 06.07.10 19:15, schrieb Marcin W. Dąbrowski: Hi. Today I hit something weird, when trying to see the history of one of the files in my repository - `mtn log filename.ext` is showing logs for other files than 'filename.ext'. I tried to find minimal case, and running the sequence you can see presented below hits the bug - or to say this in other words — it shows not exactly the information I'd like to see. [snip] I see two changelogs printed. I don't know why I see the changelog for example.txt, nor why the order is chronological (normally it should be reverse chronology - usually it is). So - is this by design (no, really?), or a bug? I think this is a fall-out of the new restrictions code which landed in 0.48 (try out 0.47 and you see the expected behaviour). We now implicitely include all parents of a node in a restriction and as such, if you log sec/second.txt, changes for sec and (the root node) are also logged. I'll try out a fix and switch the restriction handling mode to what we use also for 'revert', i.e. no implicit includes. Stay tuned and thanks for the report, 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] Possible bug in `mtn log`?
Am 06.07.10 23:10, schrieb Thomas Keller: Am 06.07.10 19:15, schrieb Marcin W. Dąbrowski: Hi. Today I hit something weird, when trying to see the history of one of the files in my repository - `mtn log filename.ext` is showing logs for other files than 'filename.ext'. I tried to find minimal case, and running the sequence you can see presented below hits the bug - or to say this in other words — it shows not exactly the information I'd like to see. [snip] I see two changelogs printed. I don't know why I see the changelog for example.txt, nor why the order is chronological (normally it should be reverse chronology - usually it is). So - is this by design (no, really?), or a bug? I think this is a fall-out of the new restrictions code which landed in 0.48 (try out 0.47 and you see the expected behaviour). We now implicitely include all parents of a node in a restriction and as such, if you log sec/second.txt, changes for sec and (the root node) are also logged. I'll try out a fix and switch the restriction handling mode to what we use also for 'revert', i.e. no implicit includes. I committed a temporary fix in branch net.venge.monotone.restriction-fixes, but this is not ready for mainline yet, because it breaks one test, namely log_--diffs. The underlying problem here is that we use the initial node restriction mask for two distinct things, for one to filter out unwanted revisions from log's display and on the other hand to create a restricted roster to iterate over when the --diffs option is supplied. The creation of the latter roster fails now though, because the parent nodes are no longer part of the node restriction. From my simple viewpoint the fix I see for this issue is to create another node restriction mask, exclusively for --diffs and build that with implicit_includes, but this sounds a little awkward to me and I wanted to hear opinions from others, namely Derek who invented all this magic :), before I do stupid things... 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
[Monotone-devel] Possible bug in 'mtn cat'
Hi. Today I've found something weird. As image says more, and working example is even better, with not further ado: - BEGIN BATCH - mtn version --full mtn -d mtn.mtn db init mtn -d mtn.mtn setup . -b mtn.bug.cat echo x example.txt mtn add example.txt mtn ci -m Added new file. mtn cat -r h: example.txt example-check.txt xxd -g8 example.txt xxd -g8 example-check.txt - END BATCH - On my machine, it gives: 2009-09-21 23:49:57,85 C:\tmp\mtn\mtn-cat-bug $ mtn version --full monotone 0.45 (base revision: a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.5 (mingw-vista special r3) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_34_1 SQLite version : 3.6.16 (compiled against 3.6.16) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.4 (compiled against 1.8.4) Changes since base revision: format_version 1 new_manifest [a4583b2d0cae8cb6889b8701543aeb4efc7e1554] old_revision [a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9] 2009-09-21 23:52:12,52 C:\tmp\mtn\mtn-cat-bug $ mtn -d mtn.mtn db init 2009-09-21 23:52:12,74 C:\tmp\mtn\mtn-cat-bug $ mtn -d mtn.mtn setup . -b mtn.bug.cat 2009-09-21 23:52:12,79 C:\tmp\mtn\mtn-cat-bug $ echo x 1example.txt 2009-09-21 23:52:12,81 C:\tmp\mtn\mtn-cat-bug $ mtn add example.txt mtn: adding example.txt to workspace manifest 2009-09-21 23:52:12,85 C:\tmp\mtn\mtn-cat-bug $ mtn ci -m Added new file. mtn: beginning commit on branch 'mtn.bug.cat' mtn: committed revision 3b2dcf8f04ccf68ef2f1959978514f12f32409d7 2009-09-21 23:52:13,21 C:\tmp\mtn\mtn-cat-bug $ mtn cat -r h: example.txt 1example-check.txt mtn: expanding selection 'h:' mtn: expanded to '3b2dcf8f04ccf68ef2f1959978514f12f32409d7' 2009-09-21 23:52:13,26 C:\tmp\mtn\mtn-cat-bug $ xxd -g8 example.txt 000: 780d0a x.. 2009-09-21 23:52:13,27 C:\tmp\mtn\mtn-cat-bug $ xxd -g8 example-check.txt 000: 780d0d0a x... Why the 0x0d (\r, CR, etc) gets doubled? PS: Running mtn cat --debug doesn't show anything interesting. Cheers, -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Possible bug in 'mtn cat'
Marcin W. Dąbrowski wrote: On my machine, it gives: 2009-09-21 23:49:57,85 C:\tmp\mtn\mtn-cat-bug $ mtn version --full monotone 0.45 (base revision: a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) This is probably a bug in Win32 native code, as I can confirm it does not happen using the Cygwin version. Please consider the Cygwin-1.7 version as a possible work-around, it's certainly a bit slower (due to the ABI emulation layer it uses) but has proper support for Unicode, which as far as I know, is a bit lacking in the Win32 native version (OTOH if you're regular Windows user you probably would feel a bit strange in a UNIX shell, as stuff is usually in different places and is done differently - Cygwin is mainly aimed a those who prefer to use UNIXes and only use Windows when necessary). Of course patches to bring the Win32 version on par with the other platforms would be very welcome! =) -- Lapo Luchini - http://lapo.it/ “It is dangerous to be right when the government is wrong.” (Voltaire) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Possible bug mentioned in logs
Hi I received this message when doing a sync over the network: mtn: beginning service on all interfaces : 4691 mtn: accepted new client connection from 204.11.129.46 : 51769 mtn: allowed '[EMAIL PROTECTED]' read permission for '*' excluding '' mtn: allowed '[EMAIL PROTECTED]' write permission for '*' excluding '' mtn: finding items to synchronize: mtn: ticks: c=certificates/256, k=keys/1, r=revisions/64 mtn: ckrrrkk mtn: fatal: std::logic_error: roster.cc:600: invariant 'fetching nonexistent entry from nodes' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn --full-version', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to /home/monotone/.monotone/dump mtn: if reporting a bug, please include this file The server crashes after this and needs to be restarted. I can send the dump file (158Kb bzipped) if someone's interested. The repository is of GPL/LGPL'ed code so that could also be made available if needed. Please CC me as I'm not on the list. Cheers! Conrad smime.p7s Description: S/MIME cryptographic signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Possible bug, a conversation about branching and propagation.
I have recently desired to take my many branches and consolidate them into a larger more co-hesive project such that it may be easier for people to work with. I have used, with much confusion and difficulty, a structure such as work/_MTN (branch1) work/project1/_MTN(branch1.project1) work/project2/_MTN(branch1.project2) work/project1/test1/_MTN(branch1.project1.test1) work/project1/test2/_MTN(branch1.project1.test2) where work contains branches project1 and project 2 as granted by mtn merge_into_dir branch1.project1 branch1 project1 mtn merge_into_dir branch1.project2 branch1 project2 mtn merge_into_dir branch1.project1.test1 branch1.project1 project1/test1 mtn merge_into_dir branch1.project1.test2 branch1.project2 project1/test2 okay that's all ugly, and certainly is not clear... having them all checked out at once, allowing local commits to branch1.project1.test1 which can be propagated to branch1.project1 Okay that's really not workable in the grand scheme... and you end up with 3way merges all over since sometimes the changes within work/project1/test1 would get commited directly into branch1, instead of the correctly merged sub-tree... - What I did today that failed. (Wish I had some notation here) - means that a thing was propagated | means that a thing was branched - means pivot_rooted org.d3x0r.sack | org.d3x0r.sack.plusplus | org.d3x0r.sack.c# org.d3x0r.dekware org.d3x0r.games org.d3x0r.sack - org.d3x0r.trunk/work/sack org.d3x0r.dekware - org.d3x0r.trunk/work/dekware org.d3x0r.games - org.d3x0r.trunk/work/games which then org.d3x0r.trunk becomes a collection of all previosly poritioned out projects, which may now safely depend on each other while still maintaing their own identity. (this is what I wanted I guess in my ideal world) From this state, I can propagate org.d3x0r.trunk - org.d3x0r.sack or org.d3x0r.dekware and only those files that originated in that branch are propagated. (in reality) org.d3x0r.sack - org.d3x0r.dekware fails, as both have root nodes that conflict. propagation of org.d3x0r.trunk - org.d3x0r.sack provides a rename of the root directory to the path provided with the merge_into_dir and dekware and trunk are in sync, and no merge is nessecary. [now org.d3x0r.sack - org.d3x0r.dekware is possible] This is all so dangerous to do... I don't always want to have the coagulated project, but I would like to propagate changes made there... I suppose I could re-pivot-root delete the old root, commit to a related branch, and propagate that branch back to the original source to get the updates back out correctly... mtn -e pivot_root sack delete; mtn -Re rm delete; mtn commit -m Updated changes -b org.d3x0r.trunk.sack mtn propagate org.d3x0r.trunk.sack org.d3x0r.sack but I think that that will cause a great deal of excessive information beyond just a simple merge... I guess all the deleted file entries from the restoration of .sack from .trunk (.trunk.sack), will only exist once... but I do then have to remember org.d3x0r.trunk-org.d3x0r.trunk.sack-org.d3x0r.sack ... the reverse is easy org.d3x0r.sack - org.d3x0r.trunk ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] possible bug
% mtn list unknown mtn: fatal: std::logic_error: paths.cc:255: invariant 'I(utf8_validate(path))' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn --full-version', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to /home/feuerbach/_MTN/debug mtn: if reporting a bug, please include this file % mtn --full-version monotone 0.30 (base revision: 843924a5e7fd46b3fa2c531eb28ae597b6172aed) Running on : Linux 2.6.17.8 #1 Sun Aug 27 20:30:39 EEST 2006 i686 C++ compiler: GNU C++ version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) C++ standard library: GNU libstdc++ version 20060507 Boost version : 1_33_1 Changes since base revision: unknown If you need some more info please note that I'm not subscribed to this list. -- Roman I. Cheplyaka started up on Linux 2.6.17.8 #1 Sun Aug 27 20:30:39 EEST 2006 i686 command line: 'mtn', 'list', 'unknown' set locale: LC_ALL=LC_CTYPE=ru_UA.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=ru_UA.UTF-8;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C initial abs path is: /home/feuerbach initializing from directory /home/feuerbach searching for '_MTN' directory with root '/' search for '_MTN' ended at '/home/feuerbach' with '' removed working root is '/home/feuerbach' initial relative path is '' local dump path is _MTN/debug setting dump path to _MTN/debug skipping nonexistent rcfile '/home/feuerbach/.monotone/monotonerc' skipping nonexistent rcfile '_MTN/monotonerc' executing command 'list' options path is _MTN/options branch name is 'main' options path is _MTN/options options path is _MTN/options revision path is _MTN/revision executing SQL 'SELECT sql FROM sqlite_master WHERE (type = 'table' OR type = 'index') AND sql IS NOT NULL AND name not like 'sqlite_stat%' ORDER BY name' result: 0 (not an error) prepared statement SELECT 1 FROM revisions LIMIT 1 prepared statement SELECT 1 FROM manifests LIMIT 1 prepared statement SELECT 1 FROM rosters LIMIT 1 prepared statement SELECT id FROM revisions WHERE id = ? prepared statement SELECT 1 FROM rosters WHERE id = ? LIMIT 1 prepared statement SELECT checksum, data FROM rosters WHERE id = ? prepared statement SELECT data FROM revisions WHERE id = ? base roster has 407 entries revision path is _MTN/revision empty include of path '.djvurc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.cdw.conf' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.ICEauthority' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.face.icon' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.fonts.conf' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.aspell.en.prepl' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.pygmyrc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.aspell.uk.prepl' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.DCOPserver_crematorium__0' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.mysql_history' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.dmrc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.zshrc~' loading lua hook ignore_file lua: extracted bool = 1 empty include of path '.xsession-errors' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.getmaillog' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.sversionrc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.shellopts' empty include of path '.vimrc' empty include of path '.buffy' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.xsession' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.signature' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.xinitrc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.audacity' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.zsh-hist' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.DCOPserver_localhost_:0' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.lesshst' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.mailfilterlog' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.aliases' empty include of path '.kderc' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.aspell.ru.pws' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.ispell_default' loading lua hook ignore_file lua: extracted bool = 0 empty include of path '.reportbugrc' loading lua hook ignore_file
[Monotone-devel] Possible Bug in Montone
Hi I was trying to set up an Open Embedded environment using their instruction but their database seems to have been prepared with an older version of Monotone. During the conversion from their generation database to the current generation seems to have gone a bit wrong. I've appended the log. I'm running SUSE 10.0 on a Pentium processor with 128MBytes of memory. Boost and Monotone were built from source 23/9/06. If you need anymore information, please email me. Hope this helps. Regards, Glyn --- [EMAIL PROTECTED]:~/monotone-0.30 make check [Snip] Of 371 tests run: 340 succeeded 0 failed 31 had expected failures 0 succeeded unexpectedly 0 were skipped PASS: run_lua_tests == All 3 tests passed == make[3]: Leaving directory `/home/glyn/monotone-0.30' make[2]: Leaving directory `/home/glyn/monotone-0.30' make[1]: Leaving directory `/home/glyn/monotone-0.30' [EMAIL PROTECTED]:~/monotone-0.30 cd ~/stuff [EMAIL PROTECTED]:~/stuff wget http://www.openembedded.org/snapshots/OE.mtn.bz2 [Snip] [EMAIL PROTECTED]:~/stuff bunzip2 OE.mtn.bz2 [EMAIL PROTECTED]:~/stuff mtn --db=~/stuff/OE.mtn pull monotone.openembedded.org org. openembedded.dev mtn: misuse: layout of database /home/glyn/stuff/OE.mtn doesn't match this versi on of monotone mtn: misuse: wanted schema ae196843d368d042f475e3dadfed11e9d7f9f01e, got 9d2b5d7 b86df00c30ac34fe87a3c20f1195bb2df mtn: misuse: try 'mtn db migrate' to upgrade mtn: misuse: (this is irreversible; you may want to make a backup copy first) [EMAIL PROTECTED]:~/stuff mtn --db=~/stuff/OE.mtn db regenerate_rosters mtn: regenerating cached rosters mtn: calculating rosters to regenerate mtn: regenerated mtn: 3,320/10,623mtn: fatal signal: Segmentation fault this is almost certainly a bug in monotone. please send this error message, the output of 'mtn --full-version', and a description of what you were doing to monotone-devel@nongnu.org do not send a core dump, but if you have one, please preserve it in case we ask you for information from it. Segmentation fault [EMAIL PROTECTED]:~/stuff mtn --full-version monotone 0.30 (base revision: unknown) Running on : Linux 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i6 86 C++ compiler: GNU C++ version 4.0.2 20050901 (prerelease) (SUSE Linux) C++ standard library: GNU libstdc++ version 20050901 Boost version : 1_33_1 Changes since base revision: unknown [EMAIL PROTECTED]:~/stuff ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Possible Bug in Montone
Glyn Owens [EMAIL PROTECTED] writes: [...] mtn: misuse: wanted schema ae196843d368d042f475e3dadfed11e9d7f9f01e, got 9d2b5d7 b86df00c30ac34fe87a3c20f1195bb2df mtn: misuse: try 'mtn db migrate' to upgrade mtn: misuse: (this is irreversible; you may want to make a backup copy first) [EMAIL PROTECTED]:~/stuff mtn --db=~/stuff/OE.mtn db regenerate_rosters mtn: regenerating cached rosters mtn: calculating rosters to regenerate mtn: regenerated mtn: 3,320/10,623mtn: fatal signal: Segmentation fault this is almost certainly a bug in monotone. Why did you try db regenerate_rosters rather than db migrate? Segfaulting suggests a bug, of course. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Possible Bug in Montone
On 9/24/06, Bruce Stephens [EMAIL PROTECTED] wrote: Glyn Owens [EMAIL PROTECTED] writes: [...] mtn: misuse: wanted schema ae196843d368d042f475e3dadfed11e9d7f9f01e, got 9d2b5d7 b86df00c30ac34fe87a3c20f1195bb2df mtn: misuse: try 'mtn db migrate' to upgrade mtn: misuse: (this is irreversible; you may want to make a backup copy first) [EMAIL PROTECTED]:~/stuff mtn --db=~/stuff/OE.mtn db regenerate_rosters mtn: regenerating cached rosters mtn: calculating rosters to regenerate mtn: regenerated mtn: 3,320/10,623mtn: fatal signal: Segmentation fault this is almost certainly a bug in monotone. Why did you try db regenerate_rosters rather than db migrate? Segfaulting suggests a bug, of course. I'm an OpenEmbedded developer. Our database snapshots are pre-0.30, yes, so to work with 0.30 they must be migrated (for now). I just upgraded to monotone 0.30 and it migrated just fine. Probably you did it in the wrong order, as Bruce suggests. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Possible Bug in Montone
On Sun, Sep 24, 2006 at 08:18:37PM +0100, Glyn Owens wrote: [EMAIL PROTECTED]:~/stuff wget http://www.openembedded.org/snapshots/OE.mtn.bz2 Thanks for the report. The quick solution to your problem is to use http://www.openembedded.org/snapshots/OE-this-is-for-mtn-0.30.mtn.bz2 instead. The segmentation fault is very strange; we'll see if we can fix the underlying bug too... -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Fw: monotone requested email (possible bug)
Will also happen if something is open in another sub-tree of the sub-tree above... i.e. trying to update something in dir1a/dir2a, but have something open in dir1a/dir2b ... == C:\mttestmonotone updatemonotone: selected update target b74f5f10adb1a9a6daa59e9a9ef009c9f0833795monotone: moving dir dlh/mnodecfgall - MT/tmp/5monotone: moving dir dlh - MT/tmp/4monotone: fatal: std::exception: boost::filesystem::rename: "dlh", "MT\tmp\4": Access is denied.monotone:monotone: this is almost certainly a bug in monotone.monotone: please send this error message, the output of 'monotone --full-version',monotone: and a description of what you were doing to monotone-devel@nongnu.org. monotone: wrote debugging log to C:/mttest/MT/debug == - Original Message - From: David Hoke To: monotone-devel@nongnu.org Sent: Tuesday, December 06, 2005 8:48 AM Subject: monotone requested email (possible bug) This email is the result of a solicitation by monotone's output. What I Was Doing I am considering the use of monotone, and I was experimenting, having managed to commit some changes to a (second) branch (which I incidentally misnamed - is thereany "rename branch" functionality?). I was then attempting to checkout that separate branch (to a different working copy), and see whether I actually had everything I needed to build the (sub-) systems I was placing in monotone. I was finding that I did not, and "add"ing and "commit"ing files from the original working copy, and "update"ing them to the secondary copy. This appears to have happened because I was withina sub-tree of one of the systems (in the secondary working copy) when I attempted to execute the "update". I tried the same thing again, and got similar results. When I backed up to the root of the secondary working copy and tried it, it succeeded. Perhaps a difference in *nix vs. windows - I believe win32 will let you rename files that are in use, but not directories... Perhaps *nix allows directories as well as files... === x$monotone updatemonotone: selected update target 375739dc61f7b2c97f7a900f849837f9f79c3a12monotone: moving dir dlh/utils - MT/tmp/5monotone: fatal: std::exception: boost::filesystem::rename: "dlh\utils", "MT\tmp\5": The process cannot access the file because it is being used by another process.monotone:monotone: this is almost certainly a bug in monotone.monotone: please send this error message, the output of 'monotone --full-version',monotone: and a description of what you were doing to monotone-devel@nongnu.org. monotone: wrote debugging log to C:/mttest/MT/debug === x$monotone --full-versionmonotone 0.24 (base revision: d59847072bb689e952ab21db7f9fababdb80a19f)Running on: Windows NT/2000/XP (5.1, build 2600) on ia32 (level 15, rev 1027)Changes since base revision:new_manifest [372d1c1e2c97f00c8a329d7f2dfae6ba28fe1db6] old_revision [d59847072bb689e952ab21db7f9fababdb80a19f]old_manifest [372d1c1e2c97f00c8a329d7f2dfae6ba28fe1db6] Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
