Hi Jon,
I was just testing my modification and came across another issue with
the sanity checker (see my other mail) Could you please try to uncomment
the following lines in the Dumpfile.pm:
# ($this_action, $itempath) =
# $self->_action_path_sanity_check($this_action,
$itempath, $data);
and test whether this has any influence onto the conversion? This will
disable the sanity checker.
On the other hand, did you get any error message after the conversion, like:
> Attempt to delete non-existent item '/project1/file.txt' at
revision 6; skipping...
Best regards
Dirk
Jon W schrieb:
Thanks for the update Dirk. I reran the conversion with the
--task=IMPORTSVN option, and when loading the dumpfile, it failed as
follows:
<<< Started new transaction, based on original revision 33423
* deleting path : Project/Source/Sim/foo.h ... done.
svnadmin: File not found: revision 33389, path
'/Project/socket/company/source/math/solv.cpp'
* adding path : Project/socket/company/source/math/solv.cpp ...
What happened (from looking through the partially created svn repo) is
that the file was shared between a few directories.
The file was deleted from /Project/socket/company/source/math within
revision 33353. Then, it was deleted from the other directory
/Project/source/math at revision 33390. It looks like the recover
action within the conversion is trying to grab the file from rev 33389
for /Project/socket/company/source/math, but that file doesn't exist
there. It exists in /Project/source/math at 33389, but not
Project/socket/company/source/math. It should be looking to recover
from revision 33352.
Just let me know if I can provide any more information that would help.
Thank you,
Jon
On 5/22/06, Dirk <[EMAIL PROTECTED]> wrote:
Dirk schrieb:
> Hi Jon,
>> But you can perform intensive testing after it is finished. I will
>> have some time this night. If I'm not to tired I will try to make
>> some progress on these issues.
>
> I just have reverted the delete/recover handling to the algorithm used
> in the beta-2 version. This is that the deleted items are tracked
> seperately. If you want to help, you can test the latest revision. I
> have not done intensive testing with my archive. So be aware, it could
> brake in other scenarios.
>
> There is one change from the algorithm in the beta-2 version. I needed
> to track the revision id 1 prior to the one I'm going to delete. So
> this could be a problem in the beta-2 branch, too.
>
>
###############################################################################
>
> # _delete_handler
>
###############################################################################
>
> sub _delete_handler {
> ...
>
> $self->track_deleted($data->{physname}, $data->{revision_id}-1,
> $itempath);
>
> } # End _delete_handler
>
Just another note, you can use the command line options
--resume --task=IMPORTSVN
since only the latest step needs to be rerun.
Best regards
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
_______________________________________________
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
_______________________________________________
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
