copy+modify+commit and possible adjustment to internal data structures (was Re: Invalid change ordering?)

[Dirk]

> 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?
>