bugmonotone - Bugs: bug #13178, cvs_import still produces wrong...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #13178: cvs_import still produces wrong data on branch (continuation from 13032 and 13063)

Submitted by:  None
Submitted on:  Tue 24 May 2005 09:20:52 PM UTC  
 
Category: storage systemSeverity: 3 - Normal
Item Group: incorrect behaviorStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open
mtn version --full: 

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.

Sun 12 Jun 2005 08:04:04 PM UTC, comment #2:

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.

graydon hoare <graydon>
Project Member
Sun 12 Jun 2005 07:07:39 PM UTC, comment #1:

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 -unavailable- with what I did wrong and/or a new demo that produces the bug on the new version? Thanks!

Stephen Peters <smpeters>
Tue 24 May 2005 09:20:52 PM UTC, original submission:

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.

Anonymous

 

Attached Files
file #3016:  e.tar.bz2 added by None (8KiB - application/x-bzip2 - test data for bug)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Tue 24 May 2005 09:20:52 PM UTCNoneAttached File-=>Added e.tar.bz2, #2540

Back to the top


Powered by Savane 3.1-cleanup1