How to maintain clean history in main branch?

Brian Wallis brian.wallis at infomedix.com.au
Thu Apr 24 01:38:08 CDT 2008


I am trying to follow a similar way of working and hadn't thought of  
this. I had sort of assumed that it would just work.

I had a bit of a play and you can do this quite easily *if* you name  
the branch. So the first thing you do is "hg branch branchname" and  
then continue working. When you are done you switch back to the  
default branch "hg update default" which takes you back to the branch  
point and then merge "hg merge branchname".

This seems to work as required.


ie:
@    4[tip]:1,3   5559c84adcf4   2008-04-24 16:28 +1000   bwallis
|\     merge on default
| |
| o  3   b43f80ecd290   2008-04-24 16:27 +1000   bwallis
| |    change 2 on branch
| |
| o  2   bb5b7297a7e1   2008-04-24 16:25 +1000   bwallis
|/     change on branch
|
o  1   58b77a090b36   2008-04-24 16:25 +1000   bwallis
|    first change
|
o  0   a57c0127b54f   2008-04-24 16:24 +1000   bwallis
      initial file

On 24/04/2008, at 12:50 PM, tomba wrote:
> In our company we are starting to use Mercurial, with a central main
> repository.
> We are trying to find a good way to use Mercurial.
>
> Mercurial makes it easy to work in branches and we would like to take
> advantage of this.
>
> We would like to have a main branch with clean history.
> Commits to main branch need to describe the change well, mention bug
> number if applicable, list code reviewers, list tests run, etc.
>
> Work can happen on side branches without strict commit rules.
> We want to preserve history of side branches while maintaining clean
> main trunk branch.
>
> Here is a possible procedure:
>
> A: Have central repository:
>
> o    1 base mainline
>
> B: Clone, commit work in stages, intended as a side branch:
>
>   o  4 address code review comments by Alice for bug fix X
>   |
>   |
>   o  3 improved fix for bug X
>   |
>   |
>   o  2 initial fix for bug X
>   |
>  /
> o    1 base mainline
>
> C: Ideally, we would like to do the following:
> Merge to main branch, provide a comment that summarizes development on
> side branch, push to central repository:
>
> o    5 fix for bug X, does Y, reviewer: Alice, tests run: P, Q, R.
> |\
> | |
> | o  4 address code review comments by Alice for bug fix X
> | |
> | |
> | o  3 improved fix for bug X
> | |
> | |
> | o  2 initial fix for bug X
> | |
> |/
> o    1 base mainline
>
> However, merge doesn't work:
> abort: can't merge with ancestor
>
> The reason for the merge is so that we maintain clean history in
> mainline, as shown for example by:
>
>    hg log --follow-first
>
> o 5 new fix for bug X, does Y, reviewer: Alice, tests run: P, Q, R.
>
> o 1 base mainline
>
> However, we want to maintain in the repository history the fix stages
> and changes due to review as well (in a side branch).
>
> An ugly solution is to perform a dummy change in the main branch  
> before
> merge:
>
> o    6 fix for bug X, does Y, reviewer: Alice, tests run: P, Q, R.
> |\
> | |
> o |  5 dummy change
> | |
> | |
> | o  4 address code review comments by Alice for bug fix X
> | |
> | |
> | o  3 improved fix for bug X
> | |
> | |
> | o  2 initial fix for bug X
> | |
> |/
> o    1 base mainline
>
> Still, one has to be careful so that 5 is the primary parent, and 4 is
> the secondary parent during the merge, not the reverse.
>
> Is there any better way?
> Or, does anyone have better suggestions for how to achieve this:
>  - maintain clean mainline with summary commit comments that follow  
> the
> rules
>  - maintain history in side branches
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

Brian Wallis
InfoMedix
p: 3 8615 4553 | f: 3 8615 4501 | e: brian.wallis at infomedix.com.au
Level 5, 451 Little Bourke Street, Melbourne VIC 3000





More information about the Mercurial mailing list