> 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?
Yes, that appears to be the case. Although, the VSS action isn't
being seen as a SHARE. It is used as an ADD, as the $Source node was
destroyed sometime after the SHARE. The VSS action information is
listed below.
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?
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
> 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})) {
Thank you,
Jon
_______________________________________________
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
