Ingo Schmidt wrote:
This did work out very well, and for every project I can now see where
it once came from. Is there really no way of putting something like
this into vss2svn? Maybe with a big warning "use at your own risk?"
Your patch essentially seems to be a much better approach to what I was
originally trying to do as a post-processing task with my filterorphans.cpp.
There were two basic classes of orphan I encountered:
a) 'false' orphans, where the vss2svn script had got confused, and was
treating something as an orphan despite its parent still being alive and
well (mainly due to confusing sets of moves / shares / etc.)
b) 'true' orphans, which includes files that were originally created in
a now-deleted project, or which were branches made in a now-deleted project.
For the false orphans, I put these back into the correct location.
For the true orphans, I found it caused problems to put them back in the
location as it had been at the time... and it was better to simply
classify these within the orphaned folder... i.e. rather than
orphaned/_CAAAAAAA/DongleCheck.cpp
orphaned/_DAAAAAAA/DongleCheck.dsp
orphaned/_EAAAAAAA/DongleCheck.h
... etc.
This became
orphaned/DongleCheck/DongleCheck.cpp
orphaned/DongleCheck/DongleCheck.dsp
orphaned/DongleCheck/DongleCheck.h
In fact more recently I didn't bother with either, as the newer versions
did not create 'false' orphans on my database, and no relevant orphans
seemed to be recent enough to care about. Final conversion is still on
hold, waiting for some source code re-arrangement to remove the reliance
on the SourceSafe file sharing mechanism, so I might yet change my mind
again!
This classification is, as far as I can tell, something that can only be
done manually because after the DongleCheck project had been deleted
there exists no record of where these files were originally created (a
human can use heuristics when perusing the PhysicalAction table of
"these files were all created at about the same time and just after the
DongleCheck project, and oooh, they have the right names too, so they
must go there", but an automated script would have more trouble
classifying them).
Other heuristics may also exist later in the file's history (as viewed
in SourceSafe) such as the location of subsequent check-ins, or where
the file is subsequently said to have been shared from, but at present
this information is not extracted from the database, and even then,
coverage would be patchy at best.
I do wonder, however, if there might be some way that orphans could be
better organised by default, particularly when there is a whole batch of
files added at once that "obviously" belong together. Another database I
converted a few days ago (based on a couple of projects that had been
archived off the main database a long time ago due to swamping the
global revision history) generated nearly 4500 subfolders of orphaned
due to some projects with large numbers of files having been added,
deleted, added again, branched, deleted, branched again, etc. Navigating
this orphaned folder or tracking anything that occured within it is, to
all intents and purposes, impractical (although the head revision of the
trunk does indeed match the sourcesafe version :) )
--
Stephen Lee <[EMAIL PROTECTED]>
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
