Stephen Lee wrote:
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.
Not exactly "known problems", but we are always finding new ways in
which VSS has stored its backend or did things in a way we didn't
expect. We try to account for these as we come across them; I'll try to
shed more light on some specific errors...
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]
Due to the way vss2svn retrieves data, it often doesn't know until later
that a data item refers to a "destroyed" item. Even after you use
"destroy" in VSS, there are traces left of the file. When vss2svn
encounters this (or a file that is hopelessly corrupted), it prints this
message, but there's really nothing that can be done here.
ERROR -- Attempt to add entry 'ULBAAAAA' with unknown version number
(probably destroyed)
at vss2svn.pl line 706
ERROR -- Attempt to share unknown item 'ULBAAAAA':
Pretty much more of the same.
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.
These are probably a bug in the code; I'll have to look more into that...
...
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
This is a bit trickier and I'm not sure I've ever actually seen this
error, but it probably also has to do with destroyed or corrupted files.
Basically the script found information on a commit, but can't find any
valid path to commit it to.
...
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
These are mostly self-explanatory. I've seen a couple cases of trying to
re-add the '/' folder; I don't know why VSS does that but it is safely
ignored in this case.
Despite all these errors, I tried an import anyway...
It's actually not uncommon to see that many errors when converting a
good-sized VSS repo.
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:
Yes, that seems to be the problem. Probably another item for the
sanity-checker to prevent adding the same item twice. I thought we were
already checking for that, and making sure the same file wasn't touched
twice in the same delete, but maybe we're not doing that for adds, or
maybe the label logic is bypassing it.
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)
Yes, it's possible to modify the datacache files and then use the
"resume" feature to restart the conversion at a particular point. You
may also have luck with the svndumpfilter tool, or if you're familiar
with Linux/GNU/Cygwin tools such as head and tail then you could
probably perform the edits without saving binary data through 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).
a: yes, certainly an artifact of the Notepad edits and b: not too
surprising; the pin/unpin logic can be tricky to follow.
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).
Yes, that's probably the case. Even on Windows you can use any of the
svn commands that operate directly on a URL in a directory with a
case-clash, so you can either rename or delete one of those two.
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?
As a general rule of thumb, the more "VSS features" that are used
(shares, pins, etc.), the more difficult it usually seems to get as good
of an import. Since you will likely need to change your development
model to not rely on these features anyway, I would suggest running the
conversion as you did, checking it out from SVN, then doing one final
export from VSS "on top of" the SVN checkout directory and committing to
ensure you have the latest of everything. Then rearrange your project as
necessary to not rely on those VSS features.
I filed a ticket for the duplicate-label and uninitialized-value issues,
but again there is likely not much to be done regarding the
destroyed/corrupted items.
toby
_______________________________________________
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
