Here is an example of the VSS action. Note that the file in the svn repository was created with version 1, and then the second revision of that file in svn uses the vss version 7, as version 7 was checked-in after the 05/04/01 date. $ grep build.h _vss2svn/datachache.VssAction.tmp.txt 3 HCECAAAA LWIAAAAA 1 ADD /Project/Source/build.h 2 0 \N 4056 \N LWIAAAAA 7 COMMIT /Project/Source/build.h 2 0 \N 4324 \N LWIAAAAA 8 COMMIT /Project/Source/build.h 2 0 \N 6510 HCECAAAA IANCAAAA 9 BRANCH /Project/Source/build.h 2 0 \N 16384 \N IANCAAAA 10 COMMIT /Project/Source/build.h 2 0 \N
I think, I start to understand. Since you destroyed the $Source project (which was formerly called $Project) we don't know the history of that project anymore. So we don't know that the file build.h was added to the $Project project before the 05/04/01 date. We know that we have commits before that date, but we don't have an item path where on which we can perform the commit. (except probably a lost&found directory). The first time we see a share to another project, we will fall back to an add, since we don't have an itempath to copy from. The next commits can be performed, we now have an item path. And since the commits are concrete versions in VSS we also have a version number. (in the above case 7, 8, ...) The problem is, that we don't have the correct version number for the "ADD" action, that was used instead of the SHARE.
Ok I will try to produce a test szenario and see, what I can do.
> Another issue happens in the following instance: > > $Source/dir1blah.h created > $Source/dir1/blah.h checked in version 2 > $Source/dir2/blah.h shared from $Source/dir1/blah.h > $Source/dir1/blah.h checked in version 3 > > $Source/dir1 deleted > > $Source/dir2/blah.h checked-in version 4 > > $Source/dir1 recovered > > In the svn repo, Source/dir1/blah.h is at version 3, but > Source/dir2/blah.h is at version 4. The recover did the right thing > by getting the svn revision right before the file was deleted, but the > shared file was also updated since that time in the other directory. Yes, this is a strange concept in VSS, that you can modify a deleted file ;-). This was one of my first modifications on the converter and got lost in changeset [224] when I reverted to the old delete/recover handling. In have only 3 files that have this problem, and for these files I didn't want to have this behavior. So I was lucky with the converter doing the "wrong" thing ;-) I have checked in a modification that will use both approaches: the old one for projects and the new one for files. This means, if we see a file, we recover to a specific version. If we encounter a project, we recover to the revision one prior the revision, when the project was deleted.I updated with your changes and reran the conversion with the --resume --task=BUILDACTIONHIST, but the converted svn repo was the same as the previous conversion. I'll rerun the conversion from scratch and see if that helps. Just to let you know, there was a typo in the Dumpfile.pm changes. Line 463 should be changed from: if (!defined ($data->{version}) { to: if (!defined ($data->{version})) {
Thanks. It was an untested modification ;-) and I hoped to do it right. It seems that this wasn't the case.
Dirk _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
