Tags & production questions
Zachery Hostens
context-hg at relayd.net
Thu May 3 05:47:23 UTC 2007
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
More information about the Mercurial
mailing list