Mercurial Workflow: Feature seperation via named branches

[Scott Palmer]

On 2011-06-16, at 1:39 AM, Sébastien Deleuze wrote:

> Correct me if I am wrong but if I merge feature-x in default, I have to be on default, so currently I have to update my repo after the merge commit to feature-x, and then close the branch. What is quite boring is this sequence :
>  - Work on feature-x
>  - switch to default in order to merge feature-x in default
>  - switch to feature-x to close it
>  - switch to default since feature-x is closed
> 


Yes I believe you are correct.  My mistake.

Scott

> On Thu, Jun 16, 2011 at 3:08 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> 
> 
> On Wed, Jun 15, 2011 at 7:40 PM, Sébastien Deleuze <seb at deleuze.fr> wrote:
> 
> We usually want to check that the merge is ok before closing the branch. So the workflow is not really easy and produce an artificial head for the close commit. Having thousands of these close commit heads is quite bad when viewing your grah log
>    $ hg up default
> 
>    $ hg merge feature-x
>    $ hg ci -m merge
>    $ hg up feature-x
>    $ hg ci -m 'Closed branch feature-x' --close-branch
> 
> Don't you test that the merge was ok before you check it in?  Then can't you check in the merge and close the branch at the same time?
> 
>    $ hg merge feature-x
> # check that merge is okay
>    $ hg ci -m "merge and close feature branch" --close-branch
> 
> As I understand it, the branch name is really still there anyway.. so if you had to fix something you can still update to that branch, do the fix, and close it again.  Am I wrong about that?
> 
> Interesting to read about your experience with bookmarks.  I am just writing something up to suggest a workflow based on bookmarks to our developers, but I haven't used things enough to know if we will run into the same issues.   Looks like I have a few more experiments to do!
> 
> Scott
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110616/dddaa16b/attachment.html>