> > No. Subversion way of creating tags via copying is very good
> > for branches and very, very poor for tags. For me lack of
> > tags or labels is also one of the main stoppers against
> > serious subversion use.
>
> Genuine question: Why does subversion's model of "a tag is a
> copy" not work for you?
Let's say there is module /libs/xyz in our repozitory
a) Tell me what tags where placed on /libs/xyz. Efficiently,
thats frequently used operation.
b) Give me the log entries for the changes made between xyz_1-0-8
and xyz_1-0-9. Efficiently.
c) Give me diff between xyz_1-0-8 and xyz_1-0-9. Efficiently
d) I need to place tag xyz_1-0-10 so it takes the
current /libs/xyz version but without the change to the file
aaa.cxx commited 3 revisions ago (but with change to the bbb.cxx
commited later)
e) Reconsider the efficiency of the operations above considering
my repository contains 347 separately tagged modules, a lot of
which have large history of 100 and more tags
e) I don't know anyone to commit to the tag once the tag is
placed. What could I do?
The case illustration using CVS: trunk /libs/xyz is heavily
reorganized, so I do
cvs up -r stable_tag /libs/xyz
as I use this library while working on something else
(in subversion I would svn switch)
Some days later I forgot about the tag checkout and do some
modification to the files in my xyz working copy. Then I try to
commit.
CVS refuses to commit so I know that I either should branch or
return to the trunk or resign.
Subversion allows to commit.
Build scripts checks out by the tag.
My build is no longer reproducible.
I could probably find more such scenarios...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 22:43:01 2004