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)

Submitter:  None
Submitted:  Tue 24 May 2005 09:20:52 PM UTC
 
Category:  storage system Severity:  3 - Normal
Item Group:  incorrect behavior Status:  None
Privacy:  Public Assigned 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.

* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

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 -email is 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

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

 

 

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2005-05-24 None Attached File- Added e.tar.bz2, #2540

Back to the top


Powered by Savane 3.9