> From: Giulio Troccoli [mailto:Giulio.Troccoli_at_uk.linedata.com]
>
> We are not a wed design company but we do have a web service team for
our Intranet and
> Extranet. They have been working, so far with basically a trunk and no
branches or tags. So,
> we are thinking of reorganising the repository, with the usual
trunk/branches/tags.
>
> Developers will create branches for everything, nothing will be
directly developed in trunk,
> i.e. trunk will get changed only by reintegrating branches. Is this
reasonable?
yes
>
> Tags will be created from trunk but not necessarely always from the
HEAD revision. Is this
> reasonable?
Yes
>
> They will have one or more staging areas, which will be a WC of a
specific tag, for testing.
> The Live area will also be a WC of a specific tags. Only the release
manager will be able to
> switch the staging and Live areas. Is this reasonable?
Not sure about staging areas. The live area should belong to operations.
>
> One of the developers who is working with me (I'm the SVN admin here)
on this reorganisation
> presented me with a scenario which I'm not sure how to implement.
>
> Let's supposed that Live is pointing to tag 1.1, and the staging area
is pointing to tag 1.2.
> Work is going on in branches and trunk does already contain some
changes that will released
> (tagged) in 1.3. At this point, however, something extremely urgent
comes up that need to be
> released in Live as soon as possible. How can we do that?
>
> My idea would be to create a branch from 1.1 tag (the one is in Live),
made the change (let's
> say committed in revision 1234), and tag it as 1.1.1. Using a stage
are to test tag 1.1.1 and
> then switch Live to 1.1.1. These changes will need to be done in trunk
too, which I think I
> can do with a simple merge. This will be agains what I said earlier
but it's a special case.
A process is only as good as how it works under stress, so don't
consider this a special case.
This is a quite reasonable approach.
>
> My next problem however is the current 1.2 tag. It does not have the
changes in revision
> 1234, so basically the test I'm doing on the staging area is useless,
as I could never
> release it. I would need to somehow, create a new 1.2.1 tags, as a
copy of 1.2 plus the
> changes in revision 1234.
Yes. I would have a rel 1.1 branch and a rel 1.2 branch. I would merge
from rel 1.1 to rel 1.2 to
trunk. I would tag each branch whenever I did a release.
>
> Is all this a correct way to proceed? I'm sure other people have come
across a problem
> similar to this, and I would really appreciate any input on how to
implement such process.
Basically, yes.
Now, can anyone point me to a bug tracking system that could capture
this? E.g. is there a system
That could tell me "found in 1.0, fixed in 1.1, 2.1 and 3.0"?
Received on 2010-09-15 14:20:32 CEST