I'm currently evaluating how feasible it is to transfer a SourceSafe
database for a product I am responsible for maintaining into a SVN
repository.

The current database relies quite heavily on SourceSafe's file sharing
mechanism for keeping common headers and other files synchronised
between projects within the product, and uses pinned shares for
maintenance of old versions (where each file is branched on-demand).
Several code changes will be necessary to fit within the structure of
any "more sensible" source control system!


I did however try a dummy run of vss2svn on the database and code
structure as it stands now, and encountered the following problems.
Would be interested to know if these are "known problems" with the
current alpha (0.11.0), if I'm doing something wrong, or if someone
would want more info to help track them down.


First there are a large number of errors and warnings displayed on
screen (sample of a few below, most of these errors are repeated several
times in different places in the 2> output, which is over 200k in total.
I've tweaked a few filenames slightly to genericise them in the output):

could not find ParserDetails.ini in /PerlApp/XML/SAX

WARNING: Unknown action 'ArchiveProject'

ERROR -- Attempt to add entry 'BAAAAAAA' with unknown version number
(probably destroyed)
at vss2svn.pl line 706
[very many similar lines to the above with different entry]
ERROR -- Attempt to add entry 'ULBAAAAA' with unknown version number
(probably destroyed)
at vss2svn.pl line 706
ERROR -- Attempt to share unknown item 'ULBAAAAA':

Use of uninitialized value in concatenation (.) or string at
/PerlApp/Vss2Svn/ActionHandler.pm line 397.
Use of uninitialized value in hash element at
/PerlApp/Vss2Svn/ActionHandler.pm line 1126.
Use of uninitialized value in hash element at
/PerlApp/Vss2Svn/ActionHandler.pm line 1015.
[several instances of the above line 1015 problem]
Use of uninitialized value in concatenation (.) or string at
/PerlApp/Vss2Svn/ActionHandler.pm line 465.
...
Use of uninitialized value in concatenation (.) or string at
/PerlApp/Vss2Svn/ActionHandler.pm line 263.
...
ERROR -- No more active itempath to commit to 'IYAAAAAA':
HYAAAAAA, IYAAAAAA, HYAAAAAA,
at vss2svn.pl line 706
...
ERROR -- No more active itempath to commit to 'QYAAAAAA':
HYAAAAAA, QYAAAAAA, HYAAAAAA,
at vss2svn.pl line 706
...
ERROR -- Attempt to share unknown item 'BVBAAAAA':

at vss2svn.pl line 706
ERROR -- Attempt to delete unknown item 'BVBAAAAA':

at vss2svn.pl line 706
[and similar errors for other unknown items]
...
ERROR -- Attempt to re-add directory '/' at revision 1, skipping action:
possibly missing delete
at vss2svn.pl line 851
ERROR -- Parent path missing while trying to add item
'/orphaned/_CAAAAAAA/DongleCheck.cpp' at revision 2: adding missing parents
at vss2svn.pl line 851
[and many other lines about orphans missing parents at line 851]
...
ERROR -- Attempt to share item '/Utilities/Unicode/Utilities.lib' to
'Utilities.lib' at revision 4230, but destination already exists:
possibly missing delete; skipping
at vss2svn.pl line 851
ERROR -- Could not open export file './_vss2svn/vssdata/ZV/ZVSAAAAA.9'
at vss2svn.pl line 851
...
ERROR -- Attempt to delete non-existent item '/Project/Print.cpp' at
revision 6152: possibly missing recover/add/share; skipping
at vss2svn.pl line 851



Despite all these errors, I tried an import anyway...

This got as far as:
------- Committed revision 644 >>>

<<< Started new transaction, based on original revision 645
     * adding path : labels/PRE_UNITS ... done.
     * adding path : labels/PRE_UNITS/orphaned ... done.
     * adding path : labels/PRE_UNITS/orphaned/_YUBAAAAA ... done.
[... adding various other paths ...]
     * adding path : labels/PRE_UNITS/Plugins/Motor/MotorRequest.h
...COPIED... done.
     * adding path : labels/PRE_UNITS/Plugins/Motor/MotorRequest.h
...COPIED... done.
[... and more other paths ...]

svnadmin: Invalid change ordering: new node revision ID without delete


I'm guessing that the "Invalid change ordering" was due to this attempt
to add the same file twice, I tried to find a way to edit the
vss2svn-dumpfile.txt - not that easy since most programs seem to balk at
the idea of opening a 0.8 GB text file - eventually persuaded Notepad to
 open it, and found duplicate entries, one of which I removed:

Node-path: labels/PRE_UNITS/Plugins/Motor/MotorRequest.h
Node-kind: file
Node-action: add
Node-copyfrom-rev: 644
Node-copyfrom-path: Plugins/Motor/MotorRequest.h
Prop-content-length: 10
Content-length: 10

PROPS-END


So first question is if there's a better way to remove (or prevent from
being created) such duplicate entries in the first place? I note, for
example, that a datacache.VssAction.tmp.txt shows that filename twice in
the same line (as well as other instances of files shared with it)

Output of the following command may be instructive:
D:\>grep BDBAAAAA _vss2svn\datacache.VssAction.tmp.txt | more
779     ZCBAAAAA        BDBAAAAA        1       ADD
/Classes/MotorRequest/MotorRequest.h    2       0       \N
926     YEBAAAAA        BDBAAAAA        1       SHARE
/Plugin/Motor/MotorRequest.h    2       0
/Classes/MotorRequest/MotorRequest.h
927     YEBAAAAA        BDBAAAAA        \N      DELETE
/Plugin/Motor/MotorRequest.h    2       0       \N
948     \N      BDBAAAAA        2       COMMIT
/Classes/MotorRequest/MotorRequest.h    2       0       \N
1274    YEBAAAAA        BDBAAAAA        2       SHARE
/Plugin/Motor/MotorRequest.h    2       0
/Classes/MotorRequest/MotorRequest.h
1275    \N      BDBAAAAA        3       COMMIT
/Classes/MotorRequest/MotorRequest.h\   /Plugin/Motor/MotorRequest.h\
/Plugin/Motor/MotorRequest.h    2       0       \N

etc... (all following COMMIT lines seem to include
Plugin/Motor/MotorRequest.h twice)



This then imported much further until it came to a similar duplicate
entry which I removed in a similar manner by editing the
vss2svn-dumpfile.txt in notepad.


Finally after these tweaks, it managed to complete an import. When I
compared against a checkout from SourceSafe I found the following
differences:

a) All binary files were corrupt - probably caused by my notepad edits
rather than by this tool though...

b) Some files which had gone through a rapid Unpin / Pin sequence were
at the wrong version (I think I saw this mentioned elsewhere).

c) SVN failed to complete a checkout, giving an error as follows:


[after cleanups and deleting files to get it in sync and reproduce just
the error:]
D:\>svn co file:///d:/svntest/ D:\svnheadtest -r HEAD
A    D:\svnheadtest\labels\Release 2.26\InstallImage\Install\V2.25.ipr
A    D:\svnheadtest\labels\Release 2.26\InstallImage\Install\V2.26.ipr
A    D:\svnheadtest\labels\Release 2.26\InstallImage\Install\v2.26.ipr
svn: In directory 'D:\svnheadtest\labels\Release 2.26\InstallImage\Install'
svn: Can't copy 'D:\svnheadtest\labels\Release
2.26\InstallImage\Install\.svn\tmp\text-base\v2.26.ipr.svn-base' to
'D:\svnheadtest\labels\Release
2.26\InstallImage\Install\.svn\tmp\v2.26.ipr.tmp.tmp': The system cannot
find the file specified.

(looks to me like the error is caused by the imported database having
somehow ended up with the same file twice but with different
capitalisations on a case-agnostic operating system).

At the point it got here it had, however, already checked out the vast
majority of the remainder of the data.


In this case it was a dummy run as proof of concept, but it would be
nice to at least have the option to move to SVN if the project is
re-arranged sufficiently to allow this. Are all of the above things that
are being worked on and/or for which there is a straightforward workaround?

If not, would additional data from any part of the import process be
useful or would it be worth trying to construct a minimal test case
based on actual file history for any of the above and/or to file a bug
report somewhere?

--
Stephen Lee

_______________________________________________
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