Invalid change ordering?

[Stephen Lee]

Dirk wrote:
>
> > potentially harmful - consider:
> >
> > ADD project1/
> > ADD project1/testfile.txt
> > ADD project2/
> > SHARE project2/testfile.txt (from project1/testfile.txt)
> > DELETE project1/testfile.txt
> > SHARE project1/testfile.txt (from project2/testfile.txt)
> > DELETE project2/
>
> I have to think about this a little further but have to leave for today.
> So just a fast question: Do you mean DELETE or PURGE? But it could be
> same effect in this case, since a purge of a shared item will not purge
> it from the harddisc, as long as there are active shares.
>
For the testfile.txt delete, this was a "destroy" which translates to 
"reduce reference count by 1"
For project2 this was a "destroy" which translates to "obliterate this 
item from the disk".


To expand slightly on my "opens yet another can of worms" comment...

If a commit occurs in project2 before the file is shared back, then this 
needs more intelligent commit handling... I think at the "No more active 
itempath to commit ..." error it should really be creating an orphan 
based on the last known revision and the new copy of the file (which 
would then leave the "current revision" and its checkin history in a 
similar situation to what we would have if the file had originally been 
created in project2 and then shared to project1).

I also had a further think, and with a "more intelligent" commit handler 
like this, the following additional changes could be made, so that an 
item exists in orphaned only if it does not exist elsewhere.
a) SHARE of an orphaned item can become a MOVE instead.
b) BRANCH would not need to immediately create the new orphan but merely 
record where the current revision is.
c) file MOVE from an unknown location can become a SHARE (which if the 
item is orphaned will turn back into a MOVE again)
d) file MOVE to an unknown location can become a DELETE (modified commit 
handler will recover this into orphaned if needed)
e) dir MOVE to/from an unknown location can become a MOVE to/from orphaned


Ref the branch handler... ideally, when (say) BAAAAAAA is branched at 
revision 3 to create GAAAAAAA, the internal state tracking GAAAAAAA's 
parent paths would inherit BAAAAAAA's up to revision 3. Then if GAAAAAAA 
is shared elsewhere and then branched or pinned to revision 1 or 2, it 
knows where to get this...

(This actually happened in my VSS database with one file - the PIN to a 
revision that does not exist on that physical file is semi-ignored).

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