[Monotone-devel] Anatomy of user stupidness

[Thomas Keller]

Hi all!

Now today I encountered a very weird problem with monotone. After some
playing and looking around this could be tracked down to my own, pure
stupidness, but read on:

I edited one file in my workspace (./wscript) and removed another one
which function was replaced by the first:

$ mtn rm -e osx_bundle.sh
mtn: entferne osx_bundle.sh vom Arbeitsbereich-Manifest
$ mtn automate get_revision
format_version "1"

new_manifest [add320c4926bc1e93d12c3fb24c8897d180af70e]

old_revision [c084f1392a8805f21f4d1ea71ca916de112faff0]

delete "osx_bundle.sh"

patch "wscript"
 from [103fd8daa6556d0d830f1538b64ab081478a1411]
   to [a62adeaeb1930bf390ac1a9b1f7500817eed1989]
$ mtn ci
mtn: beginne Einpflegen auf Zweig 'net.venge.monotone.guitone'
mtn: Revision c97d56a09485481e906f4bdac72d8c2eb7d9d67e eingepflegt

While executing my program (which shows a graphical version of mtn
automate inventory) I noticed that a diretory, named /libs was displayed
as "missing"; but there haven't been changes to the workspace before
(and commit would refuse my action if there would have been missing
files), so I manually checked the output of automate inventory.
automate inventory told me not at all that it was missing, but under
version control and existing ( "   " 0 0 libs/ )

This was weird because /libs was removed a few revisions ago and now not
even existing in my workspace:

$ ls -la libs
ls: libs: No such file or directory

Then I thought "maybe this was because of my recent changes in automate
inventory") and I tried to check the binary version of my monotone:

$ mtn --version
monotone 0.31 (Basis-Revision: 56cb04d7c8e8233e85612a6bd0bb0ac3f96db629)

Then I checked if this revision already contained the changes I was
after by using mtn log:

$ LC_ALL=c mtn log -d ../monotone.mtn  --to
56cb04d7c8e8233e85612a6bd0bb0ac3f96db629
mtn: error: wanted 1 rows got 0 in query: SELECT height FROM heights
WHERE revision = ?

Huh? No height for this revision? I double-checked if I could use --to
alone, and there was no hint in the --help output. By checking mtn ls
certs for that revision I could verify at least that the revision exists
in the database.

Anyways, I thought, back to my own guitone.mtn database and workspace
weirdness. Remember, the libs/ dir was not existing, but also not
mentioned as missing. I thought "lets run update and see where it goes":

$ mtn up
mtn: aktualisiere vorwärts auf dem Zweig 'net.venge.monotone.guitone'
mtn: falscher Gebrauch: Ihre Anfrage passt auf keine Nachfahren der
derzeitigen Revision.
mtn: falscher Gebrauch: Sie passt nicht einmal auf die derzeitige Revision.
mtn: falscher Gebrauch: Eventuell möchten Sie
'--revision=h:net.venge.monotone.guitone' ausführen.

This means in English:

your request matches no descendents of the current revision
in fact, it doesn't even match the current revision
maybe you want something like --revision=h:net.venge.monotone.guitone'

What?! I just committed c97d56a09485481e906f4bdac72d8c2eb7d9d67e, why
shouldn't it be possible to update from there? This was weird. I checked
the contents (unedited) of _MTN/revision:

$ cat _MTN/revision
format_version "1"

new_manifest [0000000000000000000000000000000000000001]

old_revision [c97d56a09485481e906f4bdac72d8c2eb7d9d67e]


Ok, no changes (obviously), and the revision was in place. Lets check if
it made it into the database at all:

$ mtn ls certs c97d56a09485481e906f4bdac72d8c2eb7d9d67e
mtn: falscher Gebrauch: Revision nicht gefunden:
'c97d56a09485481e906f4bdac72d8c2eb7d9d67e'

Revision not found? Weird... lets look at the last 5 revisions:

$ mtn log --last 5
mtn: Fehler: erwarte 1, erhielt 0 Zeilen in Anfrage: SELECT height FROM
heights WHERE revision = ?


Now, regenerating the caches didn't bring anything:

$ mtn db regenerate_caches
mtn: erstelle Katalog-Cache und Höhenangaben neu
mtn: neu erstellt
mtn:    8576/8576
mtn: Katalog-Cache und Höhenangaben wurden neu erstellt
$ mtn log --last 5
mtn: Fehler: erwarte 1, erhielt 0 Zeilen in Anfrage: SELECT height FROM
heights WHERE revision = ?


To make a long story short... what went wrong? It was executing

$ mtn log --last 5 -d monotone.mtn

This made monotone.mtn the default database for my current workspace
which based on a different database (guitone.mtn), and since the other
database didn't contain any of the revisions of the original ones,
things started to get messy (I separated certain branches project-wise
into several databases).

I still couldn't track down the original problem (missing libs/ dir,
obviously there where no files in --missing and no changes in the
revision), but the other problem _may_ have been easier to be tracked
down if monotone would have told me something like

Warning: changing default database of workspace to 'monotone.mtn'


Anyways, this was pure user stupidness at its best =)

Happy holidays,
Thomas.
-- 
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.berlios.de
> Music lyrics and more: http://musicmademe.com