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