Dirk wrote:
[...]
> $/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".
Before I added the delete, labelling each subproject ended up as an
empty revision in the output file.
It's more of a technical curiosity for me in this case ... labelling the
subprojects was a consecutive action to labelling the parent project, so
the "empty revision" actually gives correct behaviour. Just that it
might be correct for the wrong reason.
It ended up this way I think because we'd come from a source control
system where my hazy memory suggests each file had to be individually
labelled in a recursive operation, and indeed the some of the labels
were applied to a large number of individual files in that manner... (of
which only a few survive, as the containing project was later destroyed)
w.r.t. your patch for this problem, I applied the last of the 4 changes,
and this does indeed do the job.
I think this discussion established that the middle two changes were
unnecessary. Indeed the comment #1 just above it says "we can use this
item name, since it was valid in that time" suggesting that when that
comment was written someone was aware the item could have been deleted.
ummmm... no comment about the first change! ;)
Come to think of it, those middle two changes might have been
potentially harmful - consider:
ADD project1/
ADD project1/testfile.txt
ADD project2/
SHARE project2/testfile.txt (from project1/testfile.txt)
DELETE project1/testfile.txt
SHARE project1/testfile.txt (from project2/testfile.txt)
DELETE project2/
the share to project2 would be ignored, as project2 is later destroyed...
for the share back, before you added those lines, it simply acts the
same as a recover, but after those lines were added, it reverts to using
an ADD for this file, losing its history.
If testfile.txt is modified between being deleted from project1 and
being shared back, then that opens yet another can of worms...
--
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
