Comment 2 by Unknown User, Jun 12, 2005
I have just downloaded a fresh copy of monotone, and it seems like this problem has been fixed. Here is the version information for what I'm running bash-2.05b$ monotone --full-version monotone 0.19 (base revision: 168adf9537ff136c9b7fe7faad5991f92859390d) Running on: Linux 2.6.11-gentoo-r8 #2 SMP Mon May 16 17:32:33 Local time zone must be set--see zic i686 Changes since base revision: new_manifest [52a617d908ac6c4bb5b837ce5306f75155dc59ef] old_revision [168adf9537ff136c9b7fe7faad5991f92859390d] old_manifest [a9ee1d741b855fdcc0d038d64d913cef70da72f5] patch "po/monotone.pot" from [10e6d7cbad87eaa0dbe35c803cafa371567f024b] to [0465f6ac8d09fac5938ac067747b179aca677b67] 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. Here is the output when I ran the demo that you posted with this bug: bash-2.05b$ tar jxvf ../e.tar.bz2 ./ ./e/ ./e/src/ ./e/src/Attic/ ./e/src/Attic/objdump.c,v ./e/tests/ ./e/tests/asm-tst3.c,v ./e/tests/asm-tst4.c,v ./asm-tst3.c bash-2.05b$ monotone --db=test.db db init bash-2.05b$ monotone --db=test.db genkey foo monotone: generating key-pair 'foo' enter passphrase for key ID [foo]: confirm passphrase for key ID [foo]: monotone: storing key-pair 'foo' in database bash-2.05b$ monotone --db=test.db --branch=foo cvs_import e enter passphrase for key ID [foo]: monotone: [branches: 2] [versions: 9] monotone: phase 1 (version import) complete monotone: [branches: 2] [finished branches: 3] [finished edges: 5] [versions: 9]building branch foo.disasm-branch monotone: phase 2 (ancestry reconstruction) complete monotone: [branches: 2] [versions: 9] [written revisions: 1] monotone: verifying new revisions (this may take a while) monotone: [branches: 2] [versions: 9] [written revisions: 5] monotone: phase 3 (writing revisions) complete bash-2.05b$ monotone --db=test.db --branch=foo.disasm-branch co t bash-2.05b$ diff -u asm-tst3.c t/tests/asm-tst3.c bash-2.05b$ ls perhaps if you get the latest version of monotone, that could help. If I did something wrong in attempting to reproduce your bug, could you mail me at firstname.lastname@example.org with what I did wrong and/or a new demo that produces the bug on the new version? Thanks!
Comment 3 by Unknown User, Jun 13, 2005
the precise bug in question has been solved, but there is actually a much more subtle follow-on bug which has been identified here. essentially the root of the remaining problem (which is not reported in this BTS but which I've received in private email) is that monotone's CVS importer uses "best current" knowledge about a commit, while processing each file, to infer the global commit points. this means that if monotone processes files A and B, in order, and B contains information which would help disambiguate commits in A, the information is not used, because it is already finished consulting file A. ultimately this leads to lower-fidelity imports than we would like. the solution is simply to collect the information in a non-condensed form first, analyze it globally across the entire repository, and *then* condense it into individual commits. this is, note, how cvs2svn works (I've been studying it today); but it requires quite a bit of rewriting, so it will be a couple weeks before I can confidently say positive things about this bug. please leave this bug to me. I will stay on it until it is fixed.
Sign in to reply to this comment.
Reported by Unknown User, May 25, 2005