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
Received on Tue Jul 12 17:47:32 2005