Hi Jon,
I'm moving this discussion to the mailing list again since this is of
general interest.
To all others reading this mail: Jon is working with the pin-handler
branch and has a project that was deleted and later recovered. Since the
recover will restore the version of the item that existed before the
delete, all modifications on the subitems are lost that have been
performed between the last version and the delete. This is due to the
fact, that vss performs a per item versioning. More details can be
lookued up in the ticket #32.
> With the svn repo, the recover action is revision 34081, and it is
> recovering from revision 11978, which is when the PROJECT directory
> was created. Shouldn't it get the revision previous to when the
> directory was deleted? The file in question wasn't created at the
> same time that the directory was created, so is doesn't exist in rev
> 11978.
you are right, this is indeed a valid point. I have to look up the
details of the _track_item_paths function. This function tracks all
"valid" pathes and revisions from where we can copy-from. Currently I
create a new entry if I encounter a *new* traceable version in vss, that
is when an item is modified, so that it creates a new version. It seems,
that I missed to track the delete action.
Thanks for looking this up. I will create a test szenario for this and
see, whether I can solve this issue later easily.
Thank you for creating Ticket #32. I'm currently editing the dumpfile
and removing the "delete" and "recover" revision information.
Hopefully this won't have other side effects that I don't notice. I
was thinking about filtering this dumpfile through the svndumpfilter
to remove empty revisions (after making the edits) to see if that
helps any also.
Is there anything that I can do to help get this fix, and the "move"
command fix in the pinhandler branch?
I had a quick look into both issues, but due to a complete time
overflow, I had no time to dig into this deeper. Also for the
delete/recover issue, it seems, that the impact on the code is much
bigger than I expected. The problem is the per item versioning of VSS.
You can think of the way how the relations are stored in the files as
of a tree, somtimes with bidirectonal links between the parents to the
childs and sometimes only from the parent to the childs. For example the
information of an and addition or share is stored in the parent and the
child. But a delete for example is only stored in the parent.
We know only from the parent, that the file was deleted, and we know the
timestamp when it was deleted. But we do not know the version of the
item when it was deleted. So we can not recover the version previous to
the delete. We must introduce a dummy version or something like that.
When Toby started the converter, he was under the impression, that it is
sufficient to map all information that is stored with the parent back to
the childs. But now we have at least two scenarions, where no child
activity is recorded. I'm currently thinking of a way, how we can
recover the lost information, or whether we need to rethink the design.
So, currently there is no much you can do. I'm sorry.
But you can perform intensive testing after it is finished. I will have
some time this night. If I'm not to tired I will try to make some
progress on these issues.
The conversion is actually starting to look pretty good. I now have a
conversion with 40,000+ revisions! I still need to do diffs on all of
the files, but so far so good.
Nice to here that.
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
