> From: Giulio Troccoli [mailto:giulio.trocc...@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"?
