Hi Jon,
The first is related to how the $Project was
renamed/added/deleted/destroyed in 2001, from which that is the date
that the svn converted repo starts:
$Source 05/04/01 12:44pm Renamed $Project to $Source
$Project 05/04/01 1:08pm Added
[ Shared files in $Source to $Project ]
$Source 05/04/01 2:06pm Deleted
$Source 06/06/01 3:00pm Destroyed
So, the problem lies with files that have not been edited since the
05/04/01 date from which the renamed/added/deleted/destroyed action of
$Project happened.
For example, VSS history of foo.cpp:
v3 Bob 10/05/00 1:53p Checked in
v2 Ted 09/05/99 1:00p Checked in
v1 Bob 08/03/99 1:11p Created
The conversion then uses version 1 of foo.cpp, rather than the latest
version which would be version 3.
Do I understand this correctly: version 1 is used, when sharing the
files from $Source to $Project?
Could you please look into your VssAction file. The number in the fourth
column is the version number that should be used in the action. You
should see something like:
1720 XKBAAAAA PWAAAAAA 3 SHARE /Source/foo.cpp 2
0 /Project/foo.cpp
If there is a "1" in the fourth column, then we have to dig deeper. Do
you see any commits on the foo.cpp file in the VssAction.txt?
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 haven't checked the modification, since I hosed my test environment. I
have committed the change, so that you can continue testing.
btw, Thank you for getting the label support putback, as this is
really starting to work well on something as complex and convoluted as
my vss database.
One funny things happens with the label support. You have probably
recognized that all labels are copied to a "labels" directory. Also the
converter works completely in the root space, that is the labels
directory and your VSS projects share the same space. If you have
labeled the root project, the root space gets copied into the labels
directory, but now including the "labels" directory itself. But I
consider this a minor issue ;-)
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
