Dirk wrote:
This is indeed a problem and was part of a discussion in prior mailing
also. The problem here is, that we can not "introduce" virtual actions
into the flow of events. E.g. in the ActionHandler we detect the
deletion of the item and we delete it. Later we detect a checkin, but we
don't have an active item path anymore, so we first have to copy the
deleted item into the orphaned cache. This would introduce a new Action
which is currently not possible.
It seems to be possible to do a copy (or 'restore') and commit as a
single action. That is what I was proposing...
Further test example: after the command sequence:
echo this is my file > testfile1.txt
svn add testfile1.txt
svn ci -mrevision1
svn del testfile1.txt
svn copy testfile1.txt -rHEAD testfile2.txt
echo now it's at revision 2 and in a different place >> testfile2.txt
svn ci -mrevision2
the following revision is in the dumpfile (for the second "svn ci"),
including a single copy-and-modify node for testfile2.txt.
When viewing the log for testfile2.txt, it imports the history from
testfile1.txt as expected.
Revision-number: 6
Prop-content-length: 107
Content-length: 107
K 7
svn:log
V 9
revision2
K 10
svn:author
V 4
SLee
K 8
svn:date
V 27
2007-02-12T11:06:44.998538Z
PROPS-END
Node-path: testfile2.txt
Node-kind: file
Node-action: add
Node-copyfrom-rev: 5
Node-copyfrom-path: testfile1.txt
Text-content-length: 68
Text-content-md5: b9c43f1081bcaba20cd4d1b03e0e1d06
Content-length: 68
this is my file
now it's at revision 2 and in a different place
Node-path: testfile1.txt
Node-action: delete
* Dumped revision 6.
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.
> 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.
> 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)
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. Remaining orphans at the end of conversion would
be anything where there was no valid itempath for the item with that
physical name after the last ADD, COMMIT, MOVE (with no need to
optimistically move DELETEd items to the orphaned folder as these can be
recovered from the original path as described above when the next commit
occurs).
I'm also wondering if the gPhysInfo is laid out the right way round...
as far as I can see from the layout of the PhysicalAction file, all
operations (MOVE, SHARE, BRANCH, PIN, etc.) "know" a priori what
revision of the file they are supposed to be working on, yet the
gPhysInfo structure in ActionHandler.pm seems to be laid out in a manner
that is primarily determining what versions are available for a specific
parent, rather than what parents are available for a specific version.
Rather than looking up each parent first...
$gPhysInfo{$physname}->{parents}->{$parentphys}->{versions}->[$version]
... might it be restructured so that:
$gPhysInfo{$physname}->{parents}->{$parentphys}
gives only live parents to which the file is shared and to which a
subsequent commit would occur... (if empty, the next commit would be to
orphaned). This would make the {deleted} and {pinned} fields obsolete.
A new layout addressed something like:
$gPhysInfo{$physname}->{versions}->[$version]->{parents}->{$parentphys}
could be used to lookup what locations any given revision of the file
exists at (with the original path or enough info to reconstruct it as
needed)
On a commit, the entirety of the {parents} field could be copied to the
new item in the {versions} array, and then augmented with path / version
information. If there is no valid path, then the orphaned folder would
be used, and if the file was not orphaned in the previous revision a
copy+modify+commit from first listed path for previous version (or an
add if there was no previous revision). When adding a parent to
{versions}->[$version]->{parents}, an existing one with an undef
$parentphys can be removed as a "real" path would always be preferred to
orphaned...
I think that would simplify some of the operations I am referring to...
are there others that it would complicate?
--
Stephen Lee <[EMAIL PROTECTED]>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)
_______________________________________________
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
