Dirk wrote:
You are right, probably I should only copy the version information that
is part of the branch. I haven't thought of this problem, since I only
generated a simple sample scenario to test this. But as you write also,
the continuing flow of events will overwrite the version records. So
probably this is not of an issue. I would not swear on this. I will try
to do it correct.
Astonishingly my database actually manages to do something like this...
I won't describe it as a "problem" as the file that this happens to
should have been deleted anyway, but this converted correctly before.
Dirk, if you've still got my PhysicalAction file from earlier, and want
to bother looking into this for curiosity's sake, look at the actions on
the physical files XVSAAAAA and ULSAAAAA.
These are both branches of CNBAAAAA, but have a common parent, PLSAAAAA.
When they are share-pinned to KXVAAAAA, ULSAAAAA ends up as revision 28
of XVSAAAAA, rather than of itself, and the same occurs when the head
revision is share-pinned to SDXAAAAA.
To summarise the actions...
ULSAAAAA is a branch taken of CNBAAAAA at the head revision.
(CNBAAAAA was at revision 25, and ULSAAAAA starts at revision 26)
ULSAAAAA is renamed, and revision 27 committed.
ULSAAAAA is renamed again and revision 28 committed.
Later, revision 26 of CNBAAAAA is committed
A fresh copy of CNBAAAAA is shared into the same parent project
(PLSAAAAA), and branched to create XVSAAAAA, and after renaming
ULSAAAAA with a .bak extension, XVSAAAAA is renamed to take the place
of ULSAAAAA .
ULSAAAAA is not deleted, but remains in the PLSAAAAA project with a .bak
extension.
Further commits to XVSAAAAA occur taking it up to revision 35.
Both files are share-pinned (at their respective head revisions - 28 and
35) to a new project KXVAAAAA.
For some reason, ULSAAAAA ends up as revision 28 of XVSAAAAA rather than
of itself.
The same occurs when these two files are shared to BXWAAAAA. (although
to add yet more complication, KXVAAAAA is further branched to create
SDXAAAAA at revision 37)
The head revision, however (parent PLSAAAAA) converts ok.
This seems particularly strange since the common ancestor file
(CNBAAAAA) does not have a revision 28, so the two branches are sharing
some data structure even for newer revisions.
--
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
