On Fri, 2006-06-30 at 01:24 -0600, Bob Proulx 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.
Yes - I want a branch that represents exactly the testing workspace
but I only want it to appear to anyone else when testing is complete.
> 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.
The point of the tags is that someone has blessed this particular
group of versioned files, which in CVS are versioned individually.
> 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.
Tags don't actually have any effect on the file versioning and moving
them doesn't affect any history. It only affects which file versions
are identified by that tag.
> Avoiding that and making all operations
> versioned in subversion was a design goal.
I think this is leading to using 2 branches - one for the test snapshot,
then one for the release after someone blesses it.
> > > 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.
I think of it a different way. In CVS, files are versioned separately
and tags are the way you identify a set of file versions so you
can operate on the same set repeatably. The files are expected to
continue to change and the point of the tag is to identify the
state of a snapshot of the set. Normally you would just keep adding
new tags with increasing version numbers - and you can do that too if
you want but then everyone has to track what is the latest tagged
version. For this purpose I just want to identify the latest file
versions that have been tested together for current production and the
one to use to back it out and floating a known tag seems easier than
tracking variable ones.
> > > 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!...
The catch is that the top line needs to overlap the bottom
part independently. That is, the tester takes the current
repository head as his starting point. Meanwhile developers
may commit changes that go into the next cycle. If the
tester finds a problem with one file, with CVS he could
fix it and commit that file or ask the developer to do it,
then update that file into his workspace before the rtag
operation. If you can't do individual file changes in
subversion, I think that means the testing copy has to be
on a branch so as not to interfere with other concurrent
commits on the main trunk that we don't want to pick up
yet. But we probably do want the fix the tester adds put
into the trunk. Does that become a separate operation
or is there a way to finalize this such that the testing
workspace can be blessed into a release tag or branch and
any changes also go back into the trunk where other changes
may have occurred by now?
> NOW=$(date +%F-%T)
> svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> svn checkout $URL/branch/latest .
I don't want anything else that has been committed to the trunk
at this point other than what the tester might have changed or
requested to have changed. Isn't this operation going to pick
up unrelated new work?
> 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
I'm not sure I understand all that but I don't think it is going
to get the fixes back into the trunk as well as identifying the
branch/tag exactly as tested.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 30 20:51:04 2006