Tags & production questions

[Guido Ostkamp]

Hello Zachery,

> 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.

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.

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?

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?

Regards,

Guido