Les Mikesell wrote:
> 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?
I would look at using svnmerge.py to merge revisions from a trunk, to a QA
branch to a production branch. svnmerge.py will manage all the metadata for you
to ensure that only revisions that haven't been merged over will be merged. You
can also cherry pick revisions to merge.
You can find svnmerge.py in
http://svn.collab.net/repos/svn/trunk/contrib/client-side/
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 30 22:12:57 2006