Tags & production questions

Mark A. Flacy mflacy at verizon.net
Wed May 2 21:41:42 CDT 2007


On 2007.05.02 17:57, Guido Ostkamp wrote:
> Hello,
> 
> I am relatively new to Mercurial and have to use ClearCase at work, I am 
> partially familiar with SVN and CVS as well. I have some questions 
> regarding use of 'Tags' regarding doing productions with Mercurial.
> 
> The following situation is quite common at office:
> 
> At a certain time the team sets up a production using a number of tagged 
> (=labelled) sources , e.g. after a source code freeze. In ClearCase or CVS 
> this looks like the following (I have simplified the per file version 
> numbers a bit):
> 
> File A: 1 2    3 4 5
> File B:  1 2 3    4 5 6
>          -----> time ---->
>                ^
>                frozen & tagged Release1
> 
> So the Tag "Release1" consists of these file versions:
> 
> A: 2
> B: 3
> 
> In Mercurial or SVN the numbers are not defined per file, but per 
> repository, so the same situation would look like
> 
> File A: 1 3    6 7 9
> File B:  2 4 5    8 10 11
>          -----> time ---->
>                ^
>                frozen & tagged Release1
> 
> Tag "Release1": 5
> 
> 
> Now - while development continues with versions 6-11 - the production team 
> detects a bug. The correction is e.g. in File B ClearCase/CVS version 5, 
> or in version 10 of the Mercurial/SVN repository respectively.
> 
> With ClearCase/CVS the solution is easy: The tag label 'Release1' for the 
> file B is moved to version 5 and we can go on with a fixed production.
> 
> With SVN, the 'Tag' is realized as copy of repository version 5 to another 
> tag-specific-directory; here we can copy file B as in repository version 
> 10 on top of the tag-specific-subdirectory and are done.
> 
> The question now is: How can we solve the problem in Mercurial?
> 
> If I move the tag marker to version 10 of the repository, then I get 
> unwanted changes in File A as well which is not allowed.

What I would do is...

When you release a version, you should clone the repository into a bugfix repository.  Your bug fixes are developed in *that* repo, not the current development stream.  You can pull the fixes from the bugfix repo into the current one.


The branch support within Mercurial within a repository is not very useful, IMO.  It's too easy to screw up.


You should also look at the transplant extension.






More information about the Mercurial mailing list