There is another thing, that is not yet treated in the converter: the
flow of events is not only "specified" by the timestamp. Also the order
within the XML file is important.
Dirk schrieb:
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
_______________________________________________
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
