It seems to be possible to do a copy (or 'restore') and commit as a
single action. That is what I was proposing...
Yepp, you are right. I forgot this again while writing. This fact was
new to me in the last days.
vss2svn could do the same - when a commit is needed for a file with no
currently active path, find the last place it WAS active, and commit
to the orphaned folder, together with Node-copyfrom-rev and
Node-copyfrom-path lines for any path where the previous version had
been.
I will have a look. ... We need to transport the information about the
old path from the ActionHandler to the Dumpfile. But the info field in
COMMIT records is not used, so it should be easily possible.
> c) file MOVE from an unknown location can become a SHARE (which if the
> item is orphaned will turn back into a MOVE again)
Ähm, how do we know where to move/share from, if the "source path" is
unknown?
SHARE from any known instance of that physical file at that revision.
I was confused by the fact, that VSS does not support "project" shares.
Therefore I was wondering, how we could turn MOVEs into SHAREs. The
problem arises, if we have a MOVE without a source path and the project
itself is not orphaned. If the project is also listed in other contexts,
then this means, that the project was active in earlier versions in
other projects, but not in the current state. So even, if we can do
project SHAREs in svn, it is not promised, that we get the correct state
of the project.
I believe, that this problem is more or less a home made problem, due to
incorrect MOVE merging. I would like to see a scenario, where this
happens, and whether we can reliably share from the other parent.
> e) dir MOVE to/from an unknown location can become a MOVE to/from
> orphaned
The same problem here: what is the move source if it is unknown?
The orphaned folder, which is where vss2svn puts things with no
parent. A dir should exist in precisely one place at all times... so
the where to move to/from is easier to determine in that case (unless
you can delete/restore a dir? or is that only files? if you can, it
could exist in zero places)
Ok, this is already implemented. I simply did not understand exactly the
meaning of the point
Essentially, the ideal would be that any given revision of a file
exists in the orphaned folder only if there is no valid parent for the
current revision of the file.
This is implemented in one of my latests patches, where items are moved
out of the orphaned cache if they come to live due to a share, or whatever.
... snipped long refactoring suggestion ...
I think that would simplify some of the operations I am referring
to... are there others that it would complicate?
Naturally the whole structure grew up, while I was working on it. But
the {pinned} field had some specific reason in a rename scenario. The
problem is, that during a rename pinned files are also renamed. This is
one of the "flaws" of VSS and plagued me in real life a few times.
Therefore the code distinguishes between:
* active parents: contexts where commits are allowed, and
* vivid parents: contexts where renames are allowed
Another idea was, to search for the valid item paths in the order, in
which the parents where created. Therefore I had the {order} field to
record the parents in the correct order, and to use the {parents} field
more as a cache for all parents.
Nevertheless, your suggestion is good. I will keep it in mind, when I
look at the DELETE problem.
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
