> 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?
>
> Tags will be created from trunk but not necessarely always from the
> HEAD revision. Is this reasonable?
>
> 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?
Frankly, I wouldn't run staging or live as working copies. These are production environments not development. Your dev process should release deployable that are installed into your production environment by operations (which yes I know are sometimes the same people, but probably shouldn't be.)
> 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?
Your change to 1.1.1 should be merged to trunk, then those changes should be merged to 1.2.
We recently dropped the idea of using trunk for current development. Things work much better for us now.
> 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.
>
> 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.
You shouldn't do work in tags. As you said, you should make the code change, merge it to trunk... make a 1.2.1 branch and merge the change to that. I don't think your production environment should be running from a working copy.
Do you have a build script that creates a deployment of tag/branch that is then used to update production environment?
>
> 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.
>
> I ahve also starting looking into Mercurial, and I have the feeling
> that it may be more suitable. I don't know Mercurial well enough to
> make a call here, so any comments on this is also very much
> appreciated.
You will have the same issues with Mercurial as with svn. The implementation is different but the concepts are pretty much the same. The main difference is that with Mercurial the working copy is also the repository.
BOb
Received on 2010-09-15 16:05:24 CEST