Invalid change ordering?

[Stephen Lee]

Dirk wrote:
>
> what do you think of this patch?
>
Not tried it, but again, I think the middle changes, while they won't do 
any harm, are probably un-necessary.

If it needs a particular version of a file, then any valid copy of that 
version will do, whether the file was subsequently deleted in that 
version or not... which you choose is simply a matter of aethetics. 
Previous code just "preferred" the same path as the current action is on 
(which would make a share back to same location appear like a recover, 
and probably also makes most sense in the case of a PIN.). Your code 
prefers to share from a non-deleted source...

I guess an ideal would be to share from the same source as was used in 
VSS - perhaps while not relying on the currently ignored VSS information 
this could just as well be used as the hint for which of several copies 
of a file to use as a source for a share/branch/etc.

I'd been thinking before the weekend, and this patch has further 
convinced me that the data structures are back to front... at the moment 
versions is stored as a field within the parentphys, meaning that the 
code needs to check through each possible parent to find a specific 
version...
I was working out an alternative data structure that could probably also 
do away with some other fields (deleted, active)... that probably 
deserves its own thread though.


Re: BRANCH and then PIN to an earlier revision, I'll have a look when I 
get a chance later.

 > So the PIN, as it is implemented now, will hide all intermediate actions
 > and for the user this looks like a roll-back to an old version.

 > While thinking of it, it is exactly what it should be. But quite
 > confusing if you come from VSS ;-)

-- 
Stephen Lee <Stephen.Lee at hexagonmetrology.com>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)