Reported by Unknown User, May 25, 2005
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?13178) Since anonymous users cannot add comments, I've to create yet another bug. Graydon's last patch fixes the specific test case I provided in 13032, but there are more problems when importing my archive. I attach an archive sufficient to reproduce the problem. As before, unpack the sources, then import the content of the subdir e into a new monotone repository. Then check out the sources: mkdir temp cd temp tar jxvf PATH/TO/e.tar.bz2 monotone --db=test.db db init monotone --db=test.db genkey foo monotone --db=test.db --branch=foo cvs_import e monotone --db=test.db --branch=foo.disasm-branch co t diff -u asm-tst3.c t/tests/asm-tst3.c The last diff shouldn't lead to any output, but it currently does. What is stored on the branch is the initial revision, not verison on the branch in the ,v file. Removing the src/Attic/objdump.c,v file fixes the problem (that's the difference to the older test case where the objdump.c,v file isn't present). objdump.c,v is a new file which does not exist on the trunk. monotone version: ----------------- monotone 0.19 (base revision: 0dad47afa920a307999d13eda117836b15cd4d82) Running on: Linux 2.6.11-1.1312_FC4 #1 Sat May 14 16:19:42 EDT 2005 i686 Changes since base revision: new_manifest [a4d09e6b6d2f1c1f5581a898999453d20cdfe610] old_revision [0dad47afa920a307999d13eda117836b15cd4d82] old_manifest [8146b47ed2dfb9683de6b1cee336137c4952ad5b] patch "monotone.spec" from [1619421422b66900ee8324ed77c7c82f34d0752d] to [2205c40a59d237624645180c169f1cc69874bb31] patch "po/monotone.pot" from [85997f09b04320ce8cbc0972e57a3fbfb5be38da] to [cd8977f1c85b566a25c4720ea4daef9c140c643c] 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.
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.