It seems to be possible to do a copy (or 'restore') and commit as a
single action. That is what I was proposing...
Arrgh, I love it. what should happen if you destroy the parent project
in between?
e.g the following situation:
ss create $project1
ss add $project1/file.txt
ss commit $project1/file.txt
ss create $project2
ss share $project1/file.txt $project2
ss delete $project1 <----- please note I have deleted the project ---->
ss commit $project2/file.txt
ss purge $project2
ss undelete $project1
I can safely detect that the third commit will be a copy to orphan
before, but recovering the project will recover the project to the prior
state, without the new additions on the file.txt.
So actually we should not move the actual file to the oprhaned cache,
but the deleted "project" in the undeleted state, so that we can perform
further checkins on the subitems. Later in the recover step, we need to
copy the project from orphan again. :-((( This will be difficult.
Dirk
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?
_______________________________________________
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
