--On Friday, November 17, 2006 9:08 AM +0100 Robert Graf-Waczenski
<rgw@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
Received on Wed Nov 22 12:42:59 2006