Tags & production questions

[Zachery Hostens]

Another solution to keep these in 1 repository and prevent heads from screwing everything up (a lot of things can complain) is to do the following:

tag at rev:5 , tip is rev:10

hg up -C release1 /* watch the -C */
  /* do your bug fix */
hg ci
  /* update .hgtags */
hg merge

you could probably use a named branch if you wanted, but i find them kind of troublesome.
the above will branch at rev:5 + the bug fix, then merge the branch into tip, giving you a rev:11 that is tag:release1 + bugfix, and rev:12 which is tip + bugfix, and only a single head.

i know of no easy way to 'reverse' a single changeset onto the branch aside from manually merging.  this would have to be set along as a 'best practice' of fixing the real problem (release 1) and then merging into tip.



On Wed, 02 May 2007 21:41:42 -0500, "Mark A. Flacy" <mflacy at verizon.net> wrote:
> 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.
> 
> 
> 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
--
Zachery Hostens