Les Mikesell wrote:
> Ryan Schmidt wrote:
> > Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
> > to a file." A tag is a property of a file. (Or so I've heard. I never
> > used CVS.)
>
> It is, but the main reason you apply them is to group all the files
> you want at once. That is, if you have updated your working copy at
> some earlier time and your snapshot passes the testing, you can use
> the rtag command to apply a specified tag to the repository copy of
> all the files at the versions you have even if the repository now has
> new untested updates. A subsequent checkout/update of that tag will
> get exactly the same versions as the workspace where the tag was
> applied.
Tags in CVS are often used like cheap branches. What you describe
looks like a subversion branch. However in CVS tags can be moved.
And tag movement is an unversioned operation. No versioning of tags
exists in CVS. In subversion however all operations are versioned.
This means that the CVS operation of moving tags does not map directly
to a subversion operation. This is by design because in CVS it is
possible to completely mess up a repository by moving tags and have no
history of the action. Avoiding that and making all operations
versioned in subversion was a design goal.
> > But you could certainly
> > have a tag called "ready for beta" and simply delete it and recreate
> > it when you want to update it.
>
> That sounds reasonable. Is there a way to rename existing tags? In
> the CVS scheme I would use rtag to change the RELEASE tag to
> RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
This is just semantics but it sounds more like a branch than a tag to
me. Branches can change and mutate over time. But tags imply
something that does not change. In CVS it was just a quirk of the
implementation that that tags were also used as cheap branches.
> > Why is merging not an option?
>
> The idea is to make the system foolproof so you can have different
> groups coding, testing, and installing and the only way code gets
> to production is by the testers marking it as ready in the repository.
> Developers should never have to stop modifying the trunk and the
> installers shouldn't have to keep track of anything to get the
> latest known-working version.
I think what you just said is that people should not be merging the
data. In the situation you describe I can agree with that.
> Since subversion naturally groups files in a commit, maybe the
> tagging operation isn't needed to identify a snapshot but you
> still need a way to mark the points that have been tested.
I think because subversion versions directory trees that you can
automate making perfect merges to branches behind the scenes. People
would never have to deal with it but a script could easily do so. Of
course you have to get it going but then...
THEN=$(date +%F-%T)
svn copy $URL/trunk $URL/tags/release-$THEN
...work.test.work...
...test.work.test...GOOD.VERSION!...
NOW=$(date +%F-%T)
svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
svn checkout $URL/branch/latest .
svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
svn commit -m "$NOW -- Release latest..."
THEN=$NOW
...work.test.work...
...test.work.test...GOOD.VERSION!...
NOW=$(date +%F-%T)
svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
svn checkout $URL/branch/latest .
svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
svn commit -m "$NOW -- Release latest..."
THEN=$NOW
Or something similar.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 30 09:25:55 2006