Something I've implemented on a few projects and has worked quite well for me:
- use the 'QA' or 'UAT' or 'PRODUCTION' tags as 'moving targets'. If a project uses tags a lot, I'll split mine off into something like /environments.
- implement an automated build process (e.g. CruiseControl) that runs off of changes to these tags
- have this build process tag these 'moving target' tags at the end of a successful build, using CC's built-in build number generation. I usually put these tags in /builds.
If you have to patch, in your example, a QA build, you can then copy a new branch off the build tag that the problem was reported against. After committing your fix, you can then remove the QA tag and re-copy it off of HEAD on your patch branch.
Another neat side effect of using build tags is that it allows you to streamline you cross-branch merge process (re-seeding a branch to production for example), but that's probably something for another thread.
Cheers
Rob
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, July 12, 2005 11:45 AM
To: Gábor Szabó
Cc: Simon Lin; users@subversion.tigris.org
Subject: Re: Moving tag
On Jul 12, 2005, at 10:38 AM, Gábor Szabó wrote:
> On 7/12/05, Simon Lin <noisebar@yahoo.ca> wrote:
>
>> 5. We fix the bug. The change doesn't rely on the change we made
>> in step 3.
>> 6. Now we want move the tag 'iteration_1' on the file that we
>> changed in
>> step 5 to the head version of the file so that we can check out tag
>> 'iteration_1' and release it to QA again.
>>
>> I hope I'm not confusing anybody. This is something we do in every
>> iteration. We hope we can do the same thing in Subversion.
>>
>
> The question I'd ask is how will QA report bugs after you did this ?
> "We found a bug in iteration_1" ?
> "Which iteration_1", development will ask.
>
> I know you did it like that earlier but I think it is not correct from
> a CM point of view.
> Why not use a new tag (e.g. iteration_1.1 for the newly fixed
> version ?)
Right. If you keep changing a tag over and over, then it's really
more of a branch, isn't it?
CVS makes it easy to continually change a tag (because it's just a
collection of labels), but the cost here is that there's no record of
the change. If you keep changing the definition of the tag, then QA
is following a moving target, and there's no record of what they
tested last week. The solution is to make a bunch of separate tags,
or, create a "release branch" that you merge changes to, and have QA
test newer and newer versions of that branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 12 18:11:12 2005