VSS to SVN (Was: RE: Subversion vs CVS for document files)

[Robert Graf-Waczenski <rg...@lsoft.com>]

Spawning a new thread since this part of the discussion not exactly
fits into the old thread.

> (Even with all that, I still couldn't get vss2svn working... so we just
> left VSS+SOS in place for historical purposes and loaded the current
> revision of everything into SVN.)

We tried to use vss2svn to migrate our VSS db to SVN. It worked quite well
but some files were orphaned due to reasons that were not clearly
explainable
from looking at the history. vss2svn uses "orphans" to store files that
have undergone freaky events during their history which can not be
interpreted faithfully after the fact. If you have fiddled a lot with
sharing,
branching and pinning in VSS for a certain file, then orphaning it is
some sort of a safe resort to at least have the file in svn after the
migration. Some examples where vss2svn decided to orphanize a file were
explainable from the history in VSS, but some orphaned files appeared to
have
a rather trivial history (i.e. no sharing/branching/whatnot but only plain
changes accumulated over time).

This behavior left us with some sort of uncertain feeling in the neck
about how well the history would be represented in SVN after the migration,
so we plan to do *exactly* what you did.

Since the migration heavily depends on features of svndumpfilter and
svnadmin load, the problems we observed can not necessarily only be
blamed on vss2svn alone.

Oh, and BTW, don't ask about any log files that were written during
the migration. I had to delete the stuff from my 40GB disk which ran
full after the migration attempt. Now i have roughly 20GB free again ;-)

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: VSS to SVN (Was: RE: Subversion vs CVS for document files)

[Kenneth Porter <sh...@sewingwitch.com>]

--On Friday, November 17, 2006 9:08 AM +0100 Robert Graf-Waczenski 
<rg...@lsoft.com> wrote:

> Some examples where vss2svn decided to orphanize a file were explainable
> from the history in VSS, but some orphaned files appeared to have a
> rather trivial history (i.e. no sharing/branching/whatnot but only plain
> changes accumulated over time).

The converter extracts the history of each file in VSS into an XML file 
that is then used to guide the conversion. The XML is a text translation of 
the binary metadata in the VSS DB. You can look at the temporary files 
generated during the conversion to identify which VSS "physical" file 
represents your actual file. Then run "ssphys info" against that physical 
file to dump the XML description of its history. From this you should be 
able to determine what anomalies made it hard for the conversion script to 
figure out what to do.

When I was trying to figure out all the problems in my VSS DB, I used the 
following script to dump all the physical files in the DB. I could then 
grep through them to trace the winding paths each file took.

#!/bin/sh
CONVERTROOT=/mnt/New/root
CONVERTVSS=${CONVERTROOT}/VSS-20060921/data
CONVERTXML=${CONVERTROOT}/info
rm -Rf ${CONVERTXML}
cd ${CONVERTVSS}
for i in [a-z] ; do
        cd ${CONVERTVSS}/$i
        rm -Rf ${CONVERTXML}/$i
        mkdir -p ${CONVERTXML}/$i
        for j in *aa ; do
                echo $j
                ssphys info $j > ${CONVERTXML}/$i/$j.xml
        done
done

As you can see, I, too, did my conversion on a new disk to get the needed 
space for multiple attempts.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org