Dirk wrote:
I have twisted my head in order to conditionally increment the seen
variable for the corresponding physical file, but all I do doesn't
work correctly, since the condition heavily depends on the previous
and later actions of the item. The only real condition I found was: An
item must be committed when the next revision is based on the previous
itempath.
E.g.
* A share must be committed when it is followed by a rename action
* An add must be committed, when the item is shared
During the Dumpfile.pm this information is available (at least in my
pin_handler branch) since I track all itempaths and the corresponding
revision numbers. If I need to copy from an older revision, and the
older revision information is not yet in my cache, I must commit all
previous changes.
But this would dramatically change the workflow of the converter.
Right now the previously generated revision information is not used in
the Dumpfile.pm. It is used to grab all actions that will make up the
revision, but it is not used within one handler to perform some
specific action. So the revision generation could be merged into the
Dumpfile.pm.
But all this is very complex, just in order to merge a few more
related actions into one revision. Are there other fields, where the
revision generator could be improved?
Well truthfully I guess I really didn't put too much effort into getting
the SVN revisions 100% correct. Since it's a bit of guesswork anyway to
discern atomic commits when there are none in VSS, I wasn't too worried
about splitting some up erroneously, figuring it's better than nothing.
So really, I'm probably trying to determine SVN revisions too early in
the process if we want them to be more correct.
I'm wondering if we could move that functionality entirely to
Dumpfile.pm instead? Since I have already added the "sanity checker"
into that class, which is keeping an in-memory hash of the current SVN
structure, it may not be much more work to add to it the functionality
to keep track of when a new revision is needed. That would also
eliminate the "SvnRevisionVssAction" many-to-many table. We'd just need
to figure out the correct "rules" (like your examples above) of when a
new revision is really needed.
_______________________________________________
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
