Invalid change ordering?

[Dirk]

>>
>> Upps, ok. But isn't this a special case that a delete/add is treated as
>> one action replace? Would be interesting how this comes out in the
>> dumpfile. Because we can not easily do such a "join".
>>
> As below, a rather complicated no-op, but it does have separate 
> 'delete' and 'add' nodes.

Ok, I take everything back ;-)

> <<< Started new transaction, based on original revision 1645
>     * deleting path : labels/Release 1.0.0.6/Plugins/Flyte ... done.
>     * adding path : labels/Release 1.0.0.6/Plugins/Flyte ...COPIED... 
> done.
>     * deleting path : labels/Release 1.0.0.6/Plugins/Flyte ... done.
>     * adding path : labels/Release 1.0.0.6/Plugins/Flyte ...COPIED... 
> done.
>
> ------- Committed revision 1645 >>>

You have the same problem here, that the file is handled twice. This 
means, that in our internal bookeeping the file has two times the same 
parent. Which is actually wrong. One of these situations was a 
share/delete/share combination, that is fixed with my last patch, that I 
send out last evening. So you probably could try again, whether this 
fixes the problem also.

> I also noted that (as with the example above) there seem to be 
> legitimate cases where something gets labelled that has already been 
> labelled. In this case, $/Plugins had been labelled, and then each 
> subproject $/Plugins/xxx was seperately labelled. In other cases, 
> files might be labelled after their parent project.

I thought, that this was already handled nicely. I have to check my 
sample szenario, what will happen in this case. This is the so called 
"Label promotion" feature in VSS. You label the parent and later relabel 
a file to promote the label to a new version of the file. So this is 
"common practice" in VSS. I will check this again. Anyway I thought your 
problem is somewhere else due to the double "parents".

Dirk