Invalid change ordering?

[Stephen Lee]

Dirk wrote:
>
> > D:\test>svn ci -mtest
> > Replacing      test\test1.txt
> >
>
> 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.


Revision-number: 7304
Prop-content-length: 102
Content-length: 102

K 7
svn:log
V 4
test
K 10
svn:author
V 4
SLee
K 8
svn:date
V 27
2007-02-07T19:26:55.627998Z
PROPS-END

Node-path: orphaned/test/test1.txt
Node-kind: file
Node-action: delete

Node-path: orphaned/test/test1.txt
Node-kind: file
Node-action: add
Node-copyfrom-rev: 7303
Node-copyfrom-path: orphaned/test/test1.txt




* Dumped revision 7304.



I'd been looking at attacking this from the other side, and got 
promising looking results by inserting a "delete" when it tried to 
re-label something, but something made it lose track of its internal 
state. svnadmin load was happy with a dumpfile that gave the following 
output on import ...

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

... but vss2svn seems to have messed up its internal state and the next 
checkin within the *source* folder got changed to an add, as though it 
thought $/Plugins/xxx had been deleted.

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'd done my attempted change by adding
        if ($self->{repository}->exists ($labelpath)) {
            $self->add_error("Attempt to re-label item '$labelpath' at "
                . "revision $data->{revision_id}, deleting first");

            my $node = Vss2Svn::Dumpfile::Node->new();
            $node->set_initial_props($labelpath, $data);
            $node->{action} = 'delete';
            $node->{hideprops} = 1;

            push @$nodes, $node;
        }

just before
        $self->_create_svn_path ($nodes, $labelpath);

in DumpFile.pm's _label_handler function.

I don't entirely understand how that makes it lose track of the 
*original* path...

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