Bazaar NG workflow question - a possible solution

[Nicholas Allen]

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

The problem with checkouts would be that we would need to update to the 
tip of the trunk before committing to it. This would not be a useable 
solution for us due to the high frequency we have of commits to trunk 
and how long it would take to recompile after an update in order to 
perform the commit. Also it would not address our needs of keeping all 
developers informed about changes made in private branches (see comments 
at end...)

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

I guess PQM might be a better solution for managing the merges back to 
trunk from a private branch. I think the web interface would still be 
needed for creating the branch on the server and offering a web 
interface to it.

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

The biggest problem I see with this is that we need to inform other 
developers in our team of changes made by a developer in one of his 
branches (preferably as soon as it happens). This allows other members 
of the team to review the changes and possibly discuss them with the 
person making them. In subversion, we have hooks that check which files 
were modified and flags the commit for review by the developer mainly 
responsible for the file(s) modified. All developers are notified but 
some are marked as needing review by other members. The email also has 
links to the web interface so that reviewing someone's commit is just a 
matter of clicking on the link of one of the changed files to see a 
side-by-side diff displayed in the web browser.

If we switch to bzr we would definitely need a workflow that offerred 
the same level of notification as it is extremely useful for us and 
helps keep us up to date with what changes are being made by other 
members of the team.

Nicholas Allen