Stephen,
I also tried to run the dumpfile through "svndumpfilter" in order to extract
individual projects, however it failed:
type dumpfile.txt | svndumpfilter include "Data Logger" > dl-dumpfile
...
Revision 5496 committed as 5496.
Revision 5497 committed as 5497.
Revision 5498 committed as 5498.
Revision 5499 committed as 5499.
svndumpfilter: Invalid copy source path '/EMx Data
Logger/Source/confirm_changes_dialog.ui'
The process tried to write to a nonexistent pipe.
Not sure yet why this fails. Maybe the cmd on XP is not as robust as csh on
linux.
An option could be to write a script to remove entries from the dumpfile
myself, looks feasable as long as one makes sure the revision numbers are
without gaps.
Did you find much information about how one can edit the dump file, or is it
only from your own research?
Regards,
Rob
Robert Kluver wrote:
I saw your post in the vss2svn users mailing list. I'm tryng to convert
VSS repository to SVN and I get the same error as you. There are probably
several destroyed files in our VSS repository along with shared files. I
assume by now you have fully switched over to SVN. Did you manage to tweak
the import or did you end up just moving the files over to a new svn
repository (without history)?
No, I did the dummy run, and concluded that as it was non-trivial I would
need to dedicate some more time to it, and do this after the new year (i.e.
will be trying again shortly).
I'll check again performance with any updated version (think I saw a
message on the list recently about a new one getting created), and if I
still get the same issues will go through and manually determine the
correct location for each of the incorrectly orphaned files/projects
(probably in the region of 50 to 200, hard to tell without doing it as
there are correct orphans too), and use this for a search/replace filter
program to run over the dump file to change the paths as appropriate.
Branches seemed to work as best as I could determine, but unpinned and
repinned files were often wrong. The way these are being used they can
easily be overwritten with the correctly pinned version from sourcesafe
after import, but incorrectly orphaned files/projects need to be fixed
before import so that "label" branches work correctly.
I'll be doing another dummy run in the next day or two, simply to answer
the question of whether to do the conversion before or after attempting to
merge a development branch onto the trunk (if the conversion had gone
better the first time, we may well have converted to Subversion before this
branch was created....)
Cc-ing to list in case anyone has better suggestions for the "false orphan"
problem that sometimes occurs after files/projects have been recreated in
the location of a deleted file/project that previously used the same name.
--
Stephen Lee <Stephen.Lee at hexagonmetrology.com>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)
_______________________________________________
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
_________________________________________________________________
Type your favorite song. Get a customized station. Try MSN Radio powered
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001
_______________________________________________
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
