… proposed changes to dev workflow

[Refer to the main page for additional context.]

With all the changes to support git, how will that affect a developer’s workflow? (The committer’s workflow will be covered in a future post.)

The idea is "not much at all", and this post will try to define "not much".

Remember: all existing ways of working with hg will continue to work! These are just going to be some additional options for folks who prefer to use github & bitbucket.

Introduction

To start things off, here are the simplified workflows that describe how things currently work with the Mercurial repositories on hg.m.o and following commit policy.

This should match today’s workflow for devlopment (not commit):

Developer Action Steps Involved Pseudo Commands
First time checkout    
get copy on PC hg clone hg.m.o PC
tweak for 1 step push to try add try as pushable path
Work Cycle    
local work [1] hg commit
push to try [1] hg push magic_try_path
Review Process    
create patch attach patch to bug
Commit Process    
nag committer  

Changes for Bitbucket

As bitbucket uses mercurial as it’s primary DVCS, you might expect there to be not too many changes. That’s correct – there is just some additional steps on bitbucket so other users can see your work.

The changes from hg.m.o are italicized.

Developer Action Steps Involved Pseudo Commands
First time checkout    
  get personal copy fork on bitbucket
get copy on PC hg clone bitbucket PC
tweak for 1 step push to try add try as pushable path
Work Cycle    
local work [1] hg commit
push to try [1] hg push magic_try_path
Review Process    
create patch attach patch to bug OR hg push bitbucket and bitbucket pull request
Commit Process    
nag committer  

Changes for Github

For github, there are a few additional steps that will be supported by scripts. As above, the differences from hg.m.o are italicized.

Developer Action Steps Involved Pseudo Commands
First time checkout    
get personal copy github fork
get copy on PC git clone github PC
tweak for 1 step push to try run script to setup hg repo & git post commit hooks & refs [2]
Work Cycle    
local work [1] git commit
push to try [1] git push magic_try_remote
Review Process    
create patch attach patch to bug OR git push github and github pull request
Commit Process    
nag committer  

Notes

[1] (1, 2, 3, 4, 5, 6) these actions affect the local repository only and may actually be ‘mq’ operations for hg and ‘developer branch’ operations for git. The workflow for commit to the master respository will be in a following post.
[2] a number of existing developers have already developed scripts to support this. These will be unified and documented as part of the roll out

4 Responses to … proposed changes to dev workflow

  1. Note that the github/bitbucket fork step is not required if you’re going the attach patch to bug way.

    I’m curious, how are git pull requests going to be handled? Normally, these would be merged in mainline. But here, github mainline is a “copy” of m-c. So pushing back a merge from there to m-c is likely to be painful, both when doing it, and after the fact when dealing with the merge history.

  2. Hal Wine

    The fork step is optional, but key if you want to be part of the “social coding” advantage of github & bitbucket.

    The commit workflow changes will be in the next post – the key point is that the existing policy is still followed and enforced, just aided by some scripts to make it “one step”.

  3. IMHO, any solution that results in Bugzilla not being the single canonical place for bugs, patches, and code reviews is not going to work. I don’t see how pull requests can work sanely.

    • Actually, that could work if the git pull requests results in something that attaches patch(es) to bug(s).