Hi,
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.
I'm currently thinking about how to handle "partially" MOVEs. MOVE_TO is
easier, since we can move into the orphaned folder. MOVE_FROM is
problematic, since we need to know, whether the item exists in the
orphaned folder, so that we can move the item out of the folder. I think
this is a similar problem as the one described from Jason.
see also http://www.pumacode.org/projects/vss2svn/ticket/36
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...
Yes, this delete/commit/recover is one of the problems in the current
handling. And I'm not sure whether we can fix it. The only solutiuon is
to not delete the items, but to move them into an attic folder. There is
already a ticket for this, see
http://www.pumacode.org/projects/vss2svn/ticket/34
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.
see also http://www.pumacode.org/projects/vss2svn/ticket/35
You could ask Toby to get an account for the issue tracker also.
Dirk
_______________________________________________
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
