Invalid change ordering?

[Dirk]

Stephen Lee schrieb:
> 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).

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. The other possibilitiy is to never 
delete items, but to move them always into a "_deleted" folder, but this 
would clutter the workspace. So you have to choose between pest and 
cholera.

>
> 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.
OK.
> b) BRANCH would not need to immediately create the new orphan but 
> merely record where the current revision is.
Could be difficult.
> 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?
> d) file MOVE to an unknown location can become a DELETE (modified 
> commit handler will recover this into orphaned if needed)
OK.
> 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?


> 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 is indeed a problem and I think this could be solved by deep 
copying the branch source. I will have a look at this.

Dirk