Tags & production questions

[Zachery Hostens]

On Thu, 3 May 2007 18:47:35 +0200 (CEST), Guido Ostkamp <hg at ostkamp.fastmail.fm> wrote:
> Hello Zachery,
> 
> But in my example I already have a revision 11, so you probably mean
> revision 12 and 13.
> 
> If I understand you correctly, the procedure you outlined will create an
> unnamed branch where I would need to port back the already existing bugfix
> manually without the help of a command like 'merge' etc. Unfortunately
> there is no 'hg copy -r <rev> file' command which would be needed in this
> case so I would have to 'cat' the fixed file version to a temporary place
> and then replace the original copy and commit. All intermediate changes
> which led to the fix would be lost if I do not copy & commit them step by
> step manually.

your doing this backwards to how i said already.  you can't easily 'merge' in the sense of svn.  since you already have the bugfix checked in your only real option is to manually back port it.

> Regarding updating the '.hgtags' file: I think it would be possible to
> update the working copy to the new revision created by rev:5 + bug fix and
> then 'hg tag' that unnamed revision with its number. Do you agree? Or is
> it really necessary to edit the '.hgtags' file manually?

yes you can use hg tag.

> Regarding the merging you mentioned at the end, I think I've got a problem
> to understand this. I have rev 1-11. After I have created rev:5 + bug fix,
> why would I want to create a version 13 with tip + bugfix?
> 
> This would look like I have merged really existing and different changes
> made by someone else, while in my case the change is already part of the
> mainline in version 10. Wouldn't this lead to a merge conflict, as the
> changes are already in?

Your doing this the OPPOSITE direction as i described. for your current situation its to late unless you can rollback the rev11 bugfix.  you can backport it, then merge and ignore the conflict since its already fixed.

again:

(personal oppinion:  if you have an urgent bugfix that needs to be put into a release, than you should be fixing the release before it even touches tip.  tip does not concern release or the bug fix you need to get out at all.  as well, tip may/will have changes completely unrelated to the bug fix that effect it and may not need the bugfix at all.)

(personal oppinion:  if it wasn't important enough to need to be put into a back release when the fix was made it probably doesnt need to be put in at all.  yes there are exceptions to this situation.)


Step 1: update to the TAGGED release revision (your fixing the release, NOT the tip. so fix where the problem is most important first.)
  # hg up -C release1.0

Step 2: implement your bugfix.  (your fixing the release NOT tip.)

Step 3: checkin your bugfix.  This branches from rev:5 NOT extends tip.

                .----------------------11(rel1.1)-->(HEAD 1)
1--2--3--4--5(rel1.0)--6--7--8--9--10-------------->(HEAD 2)

Step 4: Merge.

                .----------------------11(rel1.1)--.
1--2--3--4--5(rel1.0)--6--7--8--9--10--------------12-->(HEAD 1)


this prevents you from trying to merge 5 revisions into a branch that does not need it.  Granted it would be nice if hg had a way to backport a revision to a branch/tag.  though i think hg/hg-stable have a lot better branch support then the current release.  maybe this will help in these situations in the future.


--
Zachery Hostens