Bazaar NG workflow question - a possible solution

[Erik Bågfors]

On 10/25/06, Nicholas Allen <allen at ableton.com> wrote:
> After thinking about this for a while I had the following idea as a
> possible workflow. I'm not sure what tools we would need to use here (or
> if we would have to write them ourselves) but this is how I imagine it
> could work:
>
> Each developer works on their own branch which has a mirror (push
> location) maintained on the server.
>
> A web server offers an html form that a developer can fill out to create
> a new branch and provide a description of what the branch does. There is
> also a web interface that lists all branches with their descriptions,
> who created it, and a link to browse it through a web interface.
>
> The user then does "bzr branch new-branch-url" to create a local copy of
> the newly created branch.
>
> The user works in his branch and pushes to the mirror. Occassionally
> merging the trunk into his branch. When the user pushes to the mirror an
> email is sent to all developers indicating what files were changed, with
> links to the changes that are displayed through a bzr web interface.

This sounds like a good choice for checkouts...


> Once the developer wants to merge his changes to trunk there would be a
> separate web interface that let the user do this. The user would select
> the branch to merge from and the branch to merge to. The server would
> attempt the merge, check that there were no conflicts and inform all
> developers that a branch has been merged to the trunk (again with a list
> of changed files and links to the web interface). If there were
> conflicts a message would be displayed indicating that the user needs to
> merge the parent into local branch, resolve conflicts, commit and push
> and then try again.

Personally, I don't like having to use a web interface.  You can use
PQM which will let you work in pretty much the same way but instead of
web interface, a mail is sent out from a plugin.


Can I sugest a workflow?  Perhaps it will not work for you, but we use it here..

Each developers creates a checkout of trunk, then also a private
branch. This is where they do all their work.  Once they are ready to
merge it into trunk, they simply merge it into the checkout they
created, and commits that.

Basically, it would look like this (using sftp in this example)

bzr checkout sftp://user@host/path/to/trunk
bzr branch sftp://user@host/path/to/trunk mybranch (or bzr "branch
trunk mybranch")

then the developer works in mybranch and hacks there, commits, etc
cd mybranch; hack hack hack; bzr ci ; hack hack; bzr ci; hack hack; bzr ci

then the developer merges from trunk now and then, there are two ways
to do this, from the checkout, or from the main trunk.  If the main
trunk, this is all he needs to do.
bzr merge; bzr ci -m 'merge trunk'

If he wants to merge from the checkout, he needs to update it first
(this is what I prefer because I can review the changes better)
cd ../trunk;bzr up; cd ../mybranch; bzr merge ../trunk; bzr ci -m 'merge trunk

Once he is ready to commit his branch to trunk, he does,
cd ../trunk; bzr up; bzr merge ../mytrunk; bzr ci -m 'merge mytrunk'

Would that workflow work?  It's a semi-centralized workflow.

/Erik
ps. bzr ci = bzr checkin = bzr commit
     bzr up = bzr update
-- 
google talk/jabber. zindar at gmail.com
SIP-phones: sip:erik_bagfors at gizmoproject.com
sip:17476714687 at proxy01.sipphone.com