Jump to content

First checkin after migration from v3 to v4 creates changeset number 1


Olaf Kober

Recommended Posts

Hello!

I'm trying to migrate a repository from Plastic 3 to Plastic 4 and have the same issue as described here: www.plasticscm.net/index.php?/topic/638-issues-migrating-databases-from-30-to-40. After the migration my first checkin creates a changeset number 1, not 6783 as expected.

The repository was imported from SVN into Plastic 3 about a year ago. After that we happily worked in Plastic 3 and now we want to move over to Plastic 4. At the moment of export Plastic 3 shows 6782 changesets.

The fast-export was done using Plastic 3.0.187.33:

cm fast-export Name@SERVER:8084 Name.plastic3.dat
6753 changesets retrieved
6753 changesets will be exported
93 labels will be exported
6753 changesets will be exported
6734 changesets will be exported
524 merges found
0 csets are out of order
Changeset 0@/main 1/6734. Elapsed 00:00:00.0310000
Changeset 1@/main 2/6734. Elapsed 00:00:00.2020000
Changeset 2@/main 3/6734. Elapsed 00:00:00.3120000
Changeset 3@/main 4/6734. Elapsed 00:00:00.3580000
...

The fast-import was done using Plastic 4.0.237.7:

cm fast-import Name@SERVER:8087 d:\plastic\Name.plastic3.dat
Repository Name does not exist. It will be created
100 csets. 43 sec importing. 00 sec reading file. 29 sec uploading. 13 sec checking in.
200 csets. 81 sec importing. 00 sec reading file. 58 sec uploading. 21 sec checking in.
300 csets. 89 sec importing. 00 sec reading file. 61 sec uploading. 27 sec checking in.
d:\plastic\Name.plastic3.dat correctly parsed. 6734 commits. 555109 ms
	 main
	 ...
325 branches
0 modified files found refering to an SHA instead of a mark
41907 modified files
2.659,1 Mb in blobs. 38362 blobs

Directly after the import I checked the changesets and the imported content. Everything seems fine. The latest changeset contains the same files as in Plastic 3 and also the changeset numbers are the same.

But, after modifying a file and checking in Plastic 4 creates a changeset number 1, not 6783 as expected.

Any ideas? Some hack to correct this in the database??

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...