Hi,
I'm having a minor problem with the SvnRevHandler. Within my project
there are beneath a lot of subprojects and files, also a few files, that
are shared within the project multiple times. E.g. a binary file that is
shared from a "bin" project into the "setup" project and a "test"
project. In order to create maintenance branches, I used the sharing +
pinning function. This shared all my projects and files from the main
project into a "Releases" project. Since you cannot "really" share a
project, all subproject are freshly creted in the Releases project. The
SvnRevHandler correctly detects that these mixture of multiple shares
and creates was done in one step, and that everything belongs to one
revisions.
But, the logic fails on the multiple shared item due to the
"$self->{seen}->{$physname}++" handling. Since the item was seen at
least twice during the creation of the Release path, the SvnRevHandler
brakes this action into multiple revisions.
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?
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
