Dirk wrote:
Things are looking good. I can see three major problems when comparing
the result with the VSS tree:
1. Some folders has not been moved out of the orphaned folder into
their correct locations. Example:
$ grep ~micke/hdf1/tmp/_vss2svn/datachache.PhysicalAction.tmp.txt -Ere
"(APNAAAAA.*D/)" | sort +7 -n
55445 APNAAAAA 1 \N ADD D/ 1
966346625 U1 0 \N 1 AAAAANPA 0
\N D Module\
83542 APNAAAAA \N XONAAAAA MOVE_FROM D/
1 1020887790 Admin 0 \N 5
AAAAANPA 1 \N \N
"missing" MOVE ?
Moves are recorded in the source project and the target project. If one
of the projects was destroyed we miss this information. I need to check
whether we can do something about this.
I'm pretty sure that APNAAAAA is the root of a Restored tree (into
XONAAAAA). XONAAAAA has in turn been Archived and Restored into the
current VSS database.
2. Some files (3 of them) are of the wrong revision in svn. Example:
$ grep ~micke/hdf1/tmp/_vss2svn/datachache.PhysicalAction.tmp.txt -Ere
"(ULAAAAAA)" | sort +7 -n
11862 ULAAAAAA \N NLAAAAAA ADD aIM.h
21015594151 U1 0 \N 1 AAAAAALU 1
\N \N
30277 ULAAAAAA 1 \N ADD aIM.h 2
1015594151 U1 0 \N 1 AAAAAALU 0
\N \N
76871 ULAAAAAA \N BTEAAAAA SHARE aIM.h
21035546575 U2 0 \N 2 AAAAAALU 1 \N
\N
30278 ULAAAAAA 2 \N COMMIT \N 2
1035547012 U2 0 \N 5 AAAAAALU 0 \N
Changes to aIM
30279 ULAAAAAA 3 \N COMMIT \N 2
1042730307 U2 0 \N 5 AAAAAALU 0 \N
Split name check function into two (one user/group and one machine)
$ grep ~micke/hdf1/tmp/_vss2svn/datachache.VssAction.tmp.txt -Ere
"(ULAAAAAA)"
16708 NLAAAAAA ULAAAAAA 1 ADD /O/A/a/aIM.h 2
0 \N
32301 BTEAAAAA ULAAAAAA 1 SHARE /O/C/a/aIM.h 2
0 /O/A/a/aIM.h
32371 \N ULAAAAAA 2 COMMIT /O/A/a/aIM.h\
/O/C/a/aIM.h 2 0 \N
36717 \N ULAAAAAA 3 COMMIT /O/C/a/aIM.h 2 0
\N
For some reason, the second COMMIT no longer updates both locations.
Between revision 32371 and 36717 is there any major modification to the
directory /O/A/A? For example a delete, rename, addition or something
like that?
You were right:
30278 ULAAAAAA 2 \N COMMIT \N 2
1035547012 U2 0 \N 5 AAAAAALU 0 \N
Changes to aIM
88061 NLAAAAAA \N JAAAAAAA DELETE a/
11035547551 U2 0 \N 5 AAAAAALN 1 \N
\N
30279 ULAAAAAA 3 \N COMMIT \N 2
1042730307 U2 0 \N 5 AAAAAALU 0 \N
Split name check function into two (one user/group and one machine)
88073 NLAAAAAA \N JAAAAAAA RECOVER a/
11051268572 U1 0 \N 5 AAAAAALN 1 \N
\N
56709 BTEAAAAA \N ATEAAAAA DELETE a/
11051707537 U1 0 \N 5 AAAAAETB 1 \N
\N
Delete f1/Restore f1/Delete f2. Might explain something...
3. In one folder containing word documents, all files lost their
binary bit:
$ grep ~micke/hdf1/tmp/_vss2svn/datachache.PhysicalAction.tmp.txt -Ere
"(IGBAAAAA|FPEAAAAA)" | sort +7 -n
18054 IGBAAAAA 1 \N ADD OP1.doc 2
1018015283 U2 1 \N 1 AAAAABGI 0
\N Create
90842 IGBAAAAA \N HGBAAAAA ADD OP1.doc 2
1018015283 U2 0 \N 1 AAAAABGI 1
\N \N
18055 IGBAAAAA 2 \N COMMIT \N 2
1018028866 U2 1 \N 5 AAAAABGI 0
\N Temp. checkin
18056 IGBAAAAA 3 \N COMMIT \N 2
1018880855 U2 1 \N 5 AAAAABGI 0
\N Temp. checkin
18057 IGBAAAAA 4 \N COMMIT \N 2
1018895581 U2 1 \N 5 AAAAABGI 0
\N temp
18058 IGBAAAAA 5 \N COMMIT \N 2
1018905700 U1 1 \N 5 AAAAABGI 0
\N \N
18059 IGBAAAAA 6 \N COMMIT \N 2
1018955230 U1 1 \N 5 AAAAABGI 0
\N \N
90858 IGBAAAAA \N HGBAAAAA RENAME OP1.doc 2
1018957922 U2 0 OP2.doc 5 AAAAABGI 1
\N \N
18060 IGBAAAAA 7 \N COMMIT \N 2
1018964688 U2 1 \N 5 AAAAABGI 0
\N \N
18061 IGBAAAAA 8 \N COMMIT \N 2
1019149266 U2 1 \N 5 AAAAABGI 0
\N \N
18062 IGBAAAAA 9 \N COMMIT \N 2
1019237770 U2 1 \N 5 AAAAABGI 0
\N \N
18063 IGBAAAAA 10 \N COMMIT \N 2
1019574955 U2 1 \N 5 AAAAABGI 0
\N More written
18064 IGBAAAAA 11 \N COMMIT \N 2
1019819568 U2 1 \N 5 AAAAABGI 0
\N Corrections after review
18065 IGBAAAAA 12 \N COMMIT \N 2
1021572525 U2 1 \N 5 AAAAABGI 0
\N Revision number(s) updated.
18066 IGBAAAAA 13 \N COMMIT \N 2
1021997092 U3 1 \N 5 AAAAABGI 0
\N New version of Create
18067 IGBAAAAA 14 \N COMMIT \N 2
1022079389 U2 1 \N 5 AAAAABGI 0
\N Lock workstation replaced
18068 IGBAAAAA 15 \N COMMIT \N 2
1034849056 U1 1 \N 5 AAAAABGI 0
\N V1.2 updates
18069 IGBAAAAA 16 \N COMMIT \N 2
1034851216 U1 1 \N 5 AAAAABGI 0
\N \N
10113 IGBAAAAA \N DPEAAAAA SHARE OP2.doc 2
1034852032 U1 0 \N 2 AAAAABGI 1
\N \N
90889 IGBAAAAA \N HGBAAAAA DELETE OP2.doc 2
1034852622 U1 0 \N 5 AAAAABGI 1
\N \N
36459 FPEAAAAA 15 \N BRANCH OP2.doc 2
1034856372 Admin 1 IGBAAAAA 3 AAAAAEPF
0 \N \N
10114 FPEAAAAA \N DPEAAAAA BRANCH OP2.doc 2
1034856376 Admin 0 IGBAAAAA 3 AAAAAEPF
1 \N \N
All files (such as FPEAAAAA) have lost their binary bit in DPEAAAAA.
Just a dump question? Can you locate those files in the VSS Explorer? Do
they have the binary bit set?
All files are marked as binary in VSS. No problem there.
Actually the binary flag is stored with the file item. All those
PhysicalActions above, that have an binary flag of "0" are project
actions, that do not know about the binary flag of the file item. Since
sharing is only a project item action, there is no corresponding child
record. So the binary flag is "lost" in the MergeParentData step. We
need a separate handling of those actions in order to handle the situation.
How does this issue exhibit itself?
It is very tricky to detect. It shows itself only if the file contains
CR CR/LF LF combinations that are "eaten" by subversion and "restored"
by the checkout into CR/LF on Windows. Thus most files are "correct" and
only some exhibit checksum errors. A future modification of a
"correct" file might corrupt that file in the same way.
Regards,
/Micke
_______________________________________________
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
