On 5/29/06, Dirk <[EMAIL PROTECTED]> wrote:
Hi Jon, hi Kenneth,
I have refactored the sanity checker in the pin handler branch, and the
dumpfile finally loaded with my archive including Label support. Your
mileage may vary, but I would suggest to perform any further testing
with this code, since you will need it for the label tracking anyway.
for the refactoring I moved the sanity checker into a seperate module
and moved all checks into the specific action handlers. If a
precondition is not fullfilled an alternative is action is used, or the
action is skipped. If this happens you will errors in the end of the
conversion.
There is one problem, which I not sure, whether it will plague us, or
not. The sanity checker will not track the state of the repository
throughout all the revisions. It will only keep the state of the last
revision. If a directory is deleted the itempath is put aside until it
is recovered again, regardless of the revision. This should be okay,
since VSS can not share projects, if you share a project, it will create
a copy. So we should never see a copy-from an arbitrary revision for a
project. Deleting/recovering files is no problem. So this handling
should be ok. In my archive, I havn't used this construct, so I can't test.
That said, I will release the code to the public for a wider testing.
Hi Dirk. The label support and new changes look really nice. I did
notice a couple of minor issues as listed below.
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.
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.
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.
Thanks,
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
