Alexandre Ferrieux wrote:
Now, I'm witnessing similar problems with "orphaned" files (entire
subtrees).
I have a very superficial understanding of VSS's semantics, and this
notion of
orphan file is a mystery for me.
I'll step in and give a partial answer since I've been dealing with a
similar situation...
For one case of what I'm referring to as a "true orphan" for a file, you
can see this yourself in SourceSafe...
When you select "Properties..." on one of the files that has been
branched, and go to the Links tab, you can see the branching structure
for that file, and each branch will show where one of the shared copies
of that file is (you can use the Links button to find any other shared
copies). Branches that show as "** Deleted **" are not contained within
any project, but unless you got an error like 'File
"......\SourceSafe\data\r\ryoaaaaa" not found' when opening the dialog,
these branches still exist in the underlying storage for the file.
Another case is if a file was created originally in (for example)
$/Branch1/Project/MyFile.cpp
then shared to
$/Project/MyFile.cpp
... and later Branch1 was destroyed/archived/ etc...
In this case the conversion will initially create the file as "orphaned"
and then share (copy) it to the main project.
As a test-run, I want to migrate to svn just the "trunk". To this
effect, I
use vssadmin to select just its subtree and Dump it to a .ssa file.
Then I
create an empty VSS base, and Restore the .ssa in it. I thus get a
standalone
VSS base with just my trunk. So far so good.
This tool (vss2svn) is designed to work from an empty repository, and
build it up one revision at a time, replicating all the actions you've
done. By exporting only a single branch (when you work across branches a
lot) you're making it a lot harder for it to track the history of
various changes it can't "see" any more.
Also the way you've done this is possibly creating the problem you
see... when you "restore" a project, then as I understand it all of the
files and subprojects within that project are "created" before the
project itself according to the timestamps, so vss2svn has nowhere to
put them up to the date of the Restore action, apart from the "orphaned"
folder... and this would be in addition to other sources of orphans.
Check the history on your converted database - you may find that your
main project is 'created' only during the final few revisions and then
populated by copying various items from the "orphaned" folder.
Instead you probably want to take a complete copy of the entire
sourcesafe database, possibly destroy some superfluous projects from
this copy (especially if they don't have any shared files with the
projects of interest) and then try converting it (it doesn't burn much
extra of *your* time to leave something running overnight, or in the
background while you get on with other stuff)
Now looking for the criterion deciding which files are thus handled,
the best
I can imagine is the fact that they were Branched by one of the users
in my
original, multibranch VSS base !!!
This will be the case for (most of) the files that are in individual
subfolders of 'orphaned'. Where there is a project tree hanging off an
orphaned folder this means the entire project is orphaned (perhaps due
to an archive/restore, or perhaps because the conversion script got
confused by a number of renaming and moving of the project earlier in
its history.
Does this make sense ?
Is there a way to "cut off" files from their former Shared/Branched
status in
VSS ?
I am not aware of a method. I think the file only actually disappears
from the underlying database if all shares of all branches of the file
are destroyed.
You might get this effect from other vss to svn conversion programs that
work backwards from the current project structure (and call vss itself
to get each older version of the files) rather than forwards from an
empty database though. You just need to evaluate which is most
appropriate for your needs.
The vss2svn tool would be most appropriate if you want to take the trunk
and all existing branches across to svn, as it should properly preserve
the branching structure, in which case you'd be best evaluating it in
that context... if you need a smaller database for initial tests,
perhaps destroy all but a few subprojects (in all branches) rather than
destroying all non-trunk branches.
If you do decide to attempt to take forward what I did with my
filterorphan tool (which is, in effect, just a complicated way of doing
a multiple search/replace in the dumpfile), note that you only need to
do the vss2svn part once - ideally on the entire database. You can keep
reprocessing the dumpfile in as many different ways as you like afterwards.
In my case, although I have a defined pipeline of operations that I know
works, I have still yet to do the final "live" conversion. My SourceSafe
database uses the file sharing mechanism to distribute some header files
between over a dozen subprojects for individual dlls. It would be
unrealistic to expect these changes to be manually merged across to
other copies of the files every time they changed, so I will be
adjusting the layout so that all subprojects pick up the header files
from a central "include" folder. I expect that for the initial fix of
this I will simply check in a final revision of the widely shared file
consisting of a single line #include-ing the file's new central location.
I will also be watching out for an updated vss2svn.exe to evaluate
whether it does a better job for my remaining issues that I currently
plan to manually fix-up, which are:
a) PIN -> UNPIN -> PIN sequence being interpreted as just PIN -> UNPIN
(or perhaps PIN -> PIN -> UNPIN, or possibly just UNPIN cancelling out
all PINs....?).
b) One subproject that got completely trashed during the conversion (and
which I will have to perform surgery on manually afterwards - I finally
decided to give up attempting to get the filterorphan.cpp to fix it up
for me, as some of the updated revisions needed simply didn't exist at
the right point in time in the dumpfile).
Perversely, if the updated .exe does a better job with the false orphans
without fixing one or both of the above (I will at least report back if
one comes out in time), it will be of less use due to already having the
filter in place to fix the current version's mistakes!
--
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
