On Wed, Apr 26, 2006 at 11:34:16AM +0100, Neil Murphy wrote: > I seem to have managed to crash montone. The error messages asks me to > report the problem so I am.
Thanks! > (BTW Monotone is great otherwise! Vastly better than CVS. Changesets are > very nice. The netsync access control system could provide more feedback > though; It took me ages to realize I had single not double quotes in my > read-permissions file.) Yeah, known issue... On the actual bug: the short version is, run: $ cd /e/monotone/asic3/switch/verilog $ mtn mv ../../common/verilog ../../mac_plus/verilog/timescale.v $ mtn add ../../common/verilog $ mtn mv --execute ../../mac_plug/verilog/timescale.v ../../common/verilog The actual analysis, if you're curious and for those who might want to fix the bug(s), follows :-). > /e/monotone/asic3/switch/verilog $ mtn mv --execute > ../../mac_plus/verilog/timescale.v ../../common/verilog/ > mtn: adding common to workspace manifest > mtn: renaming mac_plus/verilog/timescale.v to common/verilog in > workspace manifest > mtn: warning: destination common/verilog already exists in workspace, > skipping Hmm, so here monotone got a little confused; the case we aren't handling right (I guess) is moving a file into an _unversioned_ directory. Monotone correctly guessed that you probably wanted to add "common", but it didn't figure out that you also wanted to version "common/verilog". So it just figured you were renaming the file "../../mac_plus/verilog/timescale.v" to have the name "../../common/verilog", and happily recorded that intention. Then, of course, the --execute part failed, but it does that separately. (The trailing / doesn't make a difference, either, because that gets normalized out early on. Technically this is probably wrong in various really obscure cases like this; not sure if the work involved in making that not be the case is at all justifiable. I don't really understand the posix rules for trailing /'s anyway.) Perhaps we should wait to record the new _MTN/work until after the --execute has succeeded? Perhaps we should somehow notice that the target of a rename already exists in the filesystem as a directory, and be smarter about that? This smells like a specific patch for a more general issue, though; the semantics are a little non-obvious. > /e/monotone/asic3/switch/verilog $ mtn status > mtn: warning: expected file 'common/verilog', but it is a directory. > mtn: warning: missing common/verilog > mtn: misuse: 1 missing files; use 'mtn ls missing' to view > mtn: misuse: to restore consistency, on each missing file run either > mtn: misuse: 'mtn drop FILE' to remove it permanently, or > mtn: misuse: 'mtn revert FILE' to restore it > mtn: misuse: or to handle all at once, simply 'monotone drop --missing' > mtn: misuse: or 'monotone revert --missing' This is giving a hint as to what happened... > /e/monotone/asic3/switch/verilog $ mtn mv --execute > ../../mac_plus/verilog/timescale.v ../../common/verilog/timescale.v > mtn: fatal: std::logic_error: > /home/lapo/packaging/tmp/monotone-0.26/roster.hh:128: invariant > 'I(static_cast<bool>(d))' violated > mtn: > 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 /e/monotone/asic3/_MTN/debug > mtn: if reporting a bug, please include this file And here we try to rename a file the doesn't exist (since as far as monotone is concerned, the file ../../mac_plus/verilog/timescale.v has been renamed already and there is no longer any file there), to a location that doesn't make any sense (because as far as monotone knows, ../../common/verilog is a file, so ../../common/verilog/timescale.v is a... strange location). I'm _guessing_ the latter is what causes the invariant failure -- it's easy to imagine we forgot to put in a more specific error check for this -- but it's a little strange we don't error out first on the nonexistent source. > ----- begin 'full_version_string' (in int cpp_main(int, char**), at > /home/lapo/packaging/tmp/monotone-0.26/monotone.cc:283) > monotone 0.26 (base revision: unknown) > Running on : CYGWIN_NT-4.0 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 > C++ compiler : GNU C++ version 3.4.4 (cygming special) (gdc 0.12, > using dmd 0.125) > C++ standard library: GNU libstdc++ version 20050519 > Boost version : 1_33_1 > Changes since base revision: > format_version "1" > > new_manifest [622264d4ccf1461336f8f4a43032596ee8b4e98f] > > old_revision [cdf0e31265a271a8e9a4126e022c3018306bf3dc] > > add_file "bin/zshdiff" > content [0166ccf2a008b6e18437b590b865a5e829349c14] > > patch ".Xdefaults" > from [d7ffb8c0dfb33a3e7b6a76a74c61ef508ecc7657] > to [ac6d1239dba0b440920c1196fb152845ca4af1e3] > > patch ".ssh/known_hosts" > from [2be8faf9613dfacd44b9ffd900fb28b5c0c05ce7] > to [bf358444e41111b0f752c028890e07ce68289c6e] > > patch ".zshrc" > from [ec8990aaaa138c84cf57b336a55f02ab2cc1dfb4] > to [8534c39dcb175770811798a86164f2dbee1d50bd] > > set "bin/zshdiff" > attr "mtn:execute" > value "true" > ----- end 'full_version_string' (in int cpp_main(int, char**), at > /home/lapo/packaging/tmp/monotone-0.26/monotone.cc:283) Oh my! This is an amusing little bug too :-). Looks like this binary was built in a dir with no _MTN directory in it, and it discovered Lapo's ~/_MTN directory instead... -- Nathaniel -- "...these, like all words, have single, decontextualized meanings: everyone knows what each of these words means, everyone knows what constitutes an instance of each of their referents. Language is fixed. Meaning is certain. Santa Claus comes down the chimney at midnight on December 24." -- The Language War, Robin Lakoff _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
