You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Simon Lin <no...@yahoo.ca> on 2005/07/12 15:10:38 UTC
Moving tag
Hi,
I'm looking for some help on moving a tag which we do a lot in CVS but
haven't figured out a way to do in Subversion. The scenario is as
following:
1. We code freeze iteration 1 and release it to QA. That is, we tag the
head as 'iteration_1'.
2. We continue development in head for iteration 2 while QA is testing.
3. We make some change in head that is for iteration 2 but definitely
not for iteration 1.
4. QA find a bug in iteration 1.
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.
Regards,
Simon
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving tag
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Jul 12, 2005 at 09:10:38AM -0600, Simon Lin wrote:
> I'm looking for some help on moving a tag which we do a lot in CVS but
> haven't figured out a way to do in Subversion. The scenario is as
> following:
[...]
> 4. QA find a bug in iteration 1.
> 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.
After fixing the issue in trunk, why not just apply/merge the patch into
iteration_1?
--
Randomly Generated Tagline:
"A bug is a bug. Even if it is not a hole, it should be hunted down
and squashed, because one or more bugs can combine to become one or
more holes..." - Theo de Raadt
Re: Moving tag
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Simon Lin wrote:
> I'm looking for some help on moving a tag which we do a lot in CVS but
> haven't figured out a way to do in Subversion.
A tag in Subversion is just a copy - after all, Subversion is just a very
enhanced filesystem. So, in order to do something to a tag, you have the
whole Subversion filesystem commands at your disposal. If you use merge (as
already suggested by someone else) or delete and copy over a new version is
mostly up to you.
In the scenario you described, there is also the chance that iteration_1 is
better represented when it is considered a branch rather than a tag. It
depends a bit on your workflow and how you wrap you brain around it.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving tag
Posted by Simon Lin <no...@yahoo.ca>.
Thanks. That helped a lot.
Joshua Varner wrote:
> On 7/12/05, Simon Lin <no...@yahoo.ca> wrote:
>
>>Hi,
>>
>>I'm looking for some help on moving a tag which we do a lot in CVS but
>>haven't figured out a way to do in Subversion. The scenario is as
>>following:
>>
>>1. We code freeze iteration 1 and release it to QA. That is, we tag the
>>head as 'iteration_1'.
>>2. We continue development in head for iteration 2 while QA is testing.
>>3. We make some change in head that is for iteration 2 but definitely
>>not for iteration 1.
>>4. QA find a bug in iteration 1.
>>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.
>>
>
> What your describing is much simpler in svn than in CVS, but what you
> need is a paradigm shift. Your current workflow uses tags rather than
> a branch since branching in CVS is a pain. In svn what you would do is
> create an iteration1 branch rather than a tag. Tags in svn parlance
> are read only, whereas branches are not.
>
> Now the way you would handle the bug fixes will vary according to your
> development philosophy. In subversion itself all development occurs on
> trunk, and then changes are merged selectively onto the release
> branches. It might be more natural for your group to do the bug fixes
> on the branch and then merge those changes back to the trunk if they
> are needed (i.e the bug has not already been fixed there due to other
> changes).
>
> Either way viewing iteration1 as a branch rather than a tag will make
> applying svn to it more natural.
> Josh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving tag
Posted by Bryan Dyck <bd...@mac.com>.
On 12-Jul-05, at 10:26 AM, Bill Arnette wrote:
>> Tags in svn parlance are read only, whereas branches are not.
>>
>
> This is by convention, right? Not by anything SVN does.
Yes, it is by convention; technically, tags are read/write in the
repository unless you choose to implement a hook script to prevent
anything other than the initial tag-creation copy operation on them.
Cheers,
b
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Moving tag
Posted by Bill Arnette <Bi...@signalscape.com>.
> Tags in svn parlance are read only, whereas branches are not.
This is by convention, right? Not by anything SVN does.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving tag
Posted by Joshua Varner <jl...@gmail.com>.
On 7/12/05, Simon Lin <no...@yahoo.ca> wrote:
> Hi,
>
> I'm looking for some help on moving a tag which we do a lot in CVS but
> haven't figured out a way to do in Subversion. The scenario is as
> following:
>
> 1. We code freeze iteration 1 and release it to QA. That is, we tag the
> head as 'iteration_1'.
> 2. We continue development in head for iteration 2 while QA is testing.
> 3. We make some change in head that is for iteration 2 but definitely
> not for iteration 1.
> 4. QA find a bug in iteration 1.
> 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.
>
What your describing is much simpler in svn than in CVS, but what you
need is a paradigm shift. Your current workflow uses tags rather than
a branch since branching in CVS is a pain. In svn what you would do is
create an iteration1 branch rather than a tag. Tags in svn parlance
are read only, whereas branches are not.
Now the way you would handle the bug fixes will vary according to your
development philosophy. In subversion itself all development occurs on
trunk, and then changes are merged selectively onto the release
branches. It might be more natural for your group to do the bug fixes
on the branch and then merge those changes back to the trunk if they
are needed (i.e the bug has not already been fixed there due to other
changes).
Either way viewing iteration1 as a branch rather than a tag will make
applying svn to it more natural.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Moving tag
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 12, 2005, at 10:38 AM, Gábor Szabó wrote:
> On 7/12/05, Simon Lin <no...@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
Re: Moving tag
Posted by Gábor Szabó <sz...@gmail.com>.
On 7/12/05, Simon Lin <no...@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 ?)
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org