Hi,
For now I just modified the dump file by hand, but it's still curious.
Nevertheless, it would be interesting to know the details. In many cases
one problem is the door to a bunch of other problems ;-)
Fixing that problem solved a number of other problems until I reached
revision 3800. This is an ugly one:
At revision 3794 a label called DSS-Demo-12-02 is created from the
path /P3I/Software Engineering:
31261||ANEDAAAA|4|LABEL|/P3I/Software Engineering/|1|0|DSS-Demo-12-02
That works out fine. However, the path '/P3I/Software Engineering'
has a subdirectory called 'System Component' which, in revision 3795
gets renamed to 'SystemComponent' (the space is removed):
31262|ANEDAAAA|CNEDAAAA||RENAME|/P3I/Software Engineering/System
Component/|1|0|SystemComponent/
Finally, in revision 3800 the path '/P3I/Software
Engineering/SystemComponent/ISI/Common/' is added to the same label:
31771||JREDAAAA|5|LABEL|/P3I/Software
Engineering/SystemComponent/ISI/Common/|1|0|DSS-Demo-12-02
The path 'labels/DSS-Demo-12-02/P3I/Software Engineering/System
Component/ISI/Common' already exists from the previous LABEL action.
However 'labels/DSS-Demo-12-02/P3I/Software
Engineering/SystemComponent/ISI/Common' (without no space in
'SystemComponent') does not exist, since it was LABELed before the
RENAME.
The associated rows from PhysicalAction are:
2868|ANEDAAAA|4||LABEL|/|1|1040401208|Robertj|0||5|AAAADENA|0|DSS-Demo-12-02|Version
used for the December 18th demonstration to DSS
2869|CNEDAAAA||ANEDAAAA|RENAME|System
Component/|1|1040634208|Robertj|0|SystemComponent/|5|AAAADENC|1||
63525|JREDAAAA|5||LABEL|/|1|1040636589|Robertj|0||5|AAAADERJ|0|DSS-Demo-12-02|
Clearly the timestamp for the RENAME is later than the first LABEL.
But I can't help but to feel the two should have happened in the
reverse order. Ah well, this one can probably just be chalked up to
weirdness in the repository. I'm not sure there's anything the script
could have done to catch something like this.
Interesting finding. The problem is, that there is no "label path"
concept in VSS. Labels are concrete versions or attached to other
versions in projects or files. Label promotion is the problem here. You
have created a label at a higher level of the project tree and later
assigned the label to some other sub project. You expect, that if you
checkout by label, you will get all files from the "parent project" at
the time of the first labeling, and the files from the subproject from
the second labeling.
Now the big surprise: If you have renamed a file after the first
labeling, you will get it with the new filename and not the filename,
that was right at the time of the labeling. If this was a source code
file, you are in trouble now, since you can't build your project
anymore. :-((( Therfore renaming is a big "NoGo" in VSS. Similiar
problem for renaming shares, Grrrrrr....
filenames and project names are not "versioned" in a way that subversion
can do this. It would be a dramatic failure to reflect every rename into
each label in order to deal with the situation, this would copy the
problem from VSS to subversion, and this is one of my main reasons to
convert to subversion.
Since we have the unique phyiscal id, it should be possible to align the
phyiscal ids during the second labeling, but what would you expect? A
rename in the label path in order to get to the new name? A labeling
activity with the old name?
If the dumpfile is not loadable, then we should fix the "SanityChecker"
to deal with this situation.
Best regards
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
