Hi,
one of the last questions, I was working on was to understand the
archive/restore operations. Actually we also discovered new action id
for file archive and restores. The later action gave me a big headache,
since it was not possible for me to handle these actions correctly. The
problem comes from the fact, how physical records are linked. Normally
all additions to projects are paired in the parent and the child. For
restore file actions this is not the case. Only the parent knows, that
there was an appropriate restore, but there is no mentioning of this in
the child. There is some more glue between the physical files, that is
currently not used for the conversion, e.g the "PF" records, that will
record all parents for a specific child. These records are problematic,
since they have no timestamp. They could have happened at any point
between to version records. But these records give an additional id, of
how things might stick together.
The current design of the converter is based on the idea, that every
action is a unique record or two split records, one for the parent, and
one for the client. In the meantime we learned that this is not the
case. There are also parent/parent and parent only records.
The second idea of the converter is also, that the internal action types
are used within the BUILDACTIONHIST and in the IMPORTSVN hist step.
The third idea is that every VSS action maps to a unique SVN action
(since we have the SanityChecker, this is not the case anymore, but
still one action build up in the ActionHist is translated into one
action in the SvnImporter)
I started to think about a different approach, where we talk in VSS
record types in the first step, VSS actions between the two steps and
SVN actions in the last step. This would mean:
1:) The MergeParentData step will be obsoleted
2.) We do not need all this special handling for parent/parent records
3.) that the action_handler is redesigned to decode all known record types
4.) The mapping to the action type is based on more knowledge, than
simply one record id
Since I'm only thinking of this idea, I have not yet found the proof,
that this will solve our restore problem.
Best regards
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
