Hello Toby,
I have modified the sanity checker in the latest pin handler branch. It
has now two functions to query for existing items and their parents, one
function to get a list of directories that must be created in order to
make the path valid and one function, that will mimic the "svnadmin
load" behavoir in the sence, that it will use the provided svn dumpfile
node to perform the apropriate modification on the state of the
repository. I have also moved all "sanity checks" to the action handlers
in the Dumpfile.pm. Actually the SanityChecker module should be called
DumySvnRepository, or something like that, since it doesn't perform the
checks itself. It only provides the necessary information.
The _get_svn_struct_ref_for_move function and its logic is still the
heart of the module. It will query the tree and answer all questions in
the exists, exists_parent and get_missing_dirs.
What I broke in this modification is the "junkpath" handling. I have no
reasonable test szenario to check, how this should work, but I expect,
that this is also some kind of "sanity check" within one action handler.
Also I didn't track all revisions. Only the latest revision is available
for querying. All deleted directories are put aside and can be recovered
by providing the path name. I expect one problem here:
Since I "load" the svn nodes to perform the modifications in my
dummy-repository I can come across a situation where I need to copy-from
a previous revision. Currently I use the copy-from-path to check,
whether the path is available in the current state, and then I perform a
lookup in the deleted path list. I expect, that this will be a problem,
where someone deleted a directory and created a directory with the same
name again but with a different content.
The only alternative is to track the state for each revision. But this
would be an expensive task.
Hope I didn't messed up your code to much.
Best regards
Dirk
Hello Toby,
I'm working on my label handling and had some good progress. I'm now
stuck with a situation where a file item carries the same label as one
of the parent projects. The reason for this is, that you can label the
parent and later move the label on one of the files explicitly. In
order to track this and to fallback into a commit action, I need to
know the state of the current repository. This is exactly what you did
in your sanity checker, except, that it does not handled recursive
copying, that is, if you copy a directory, only the directory is
copied and not the childs. This is actually a similiar issue like the
delete project issue
Additionally I need to call the sanity checker from within the
_label_handler without the complete error handling.
Therefor I though about the following: would it be possible, that we
move the SanityChecker into a seperate module. It should have a query
interface, like "Does itempath exists/not exist", and a kind of replay
interface, to perform the actions of the nodes onto the current state.
Then we both could use the sanityChecker for querying, what should
happen, and finally we would apply all nodes to the checker, when we
dump them into the dumpfile. In this case the captured hierarchy would
be identical to the state of the repository. I just fear, that we also
must take care of the complete revision mapping, since in a recover
case, we must know the state of the repository at that time.
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
