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 <[EMAIL PROTECTED]>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
