Hello Jon,

-Purging all of the vss deleted files.
-Destroying unwanted directories/files
-Archiving the desired top level directory
-Restoring the archive into a new vss db.
-Running the conversion from the "trunk"
As long as you don't mind the problem of the "orphaned" directory, I can't see any bad reason for doing it this way. So, I'm not sure, what happens in "dual" archive szenarios?
This all appears to work well, and I haven't noticed any conversion
issues that don't also exist with a conversion without the
archive/restore.  But, as the conversion contains so many files it is
difficult to review, and I may be missing some issues.

the only real way to check the difference of the some specific labels / revisions later.

The archiving of the vss database seems to make for a cleaner and much
smaller conversion.  It seems as though even though files are
destroyed, some still end up in the conversion unless the project is
archived/restored, then converted.  (I really need to look into this
further, but that is definitely what appears to be happening at first
glance.)

if you have shared/branched a file into another project then two items will share the same base history. If you destroy the first file later, in this case the file is not really destroyed, since the base history is still used in another item. So it will stay there.

If you archive, it could be possible, that the archiving process will compress the unused item into branched item, so that the original file will not show up anymore.

Please let me know if this is a very bad idea, or if this process
should be just fine.
I think it is a good idea and should be definitvely considered for hosed archives. Probably the archiving step will repair a few of the problems.

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

Reply via email to