Bazaar NG workflow question

[Nicholas Allen]

Nicholas Allen wrote:
> This reply was from Andrew Bennetts. I originally asked the question 
> directly to him but should have asked it on this mailing list. Here's 
> his response:
> 
> This is independent of using the smart server.  I.e. bzr works 
> identically here
> whether you have the branch at bzr+ssh://host/my-code/foo or
> sftp://host/my-code/foo.
> 
> First, if you're after a SVN-like workflow, where all developers work on
> checkouts of the same branch, then you might find my recent blog post to be
> interesting:
> 
>     http://andrew.puzzling.org/diary/2006/October/9/20061009
> 
> (apologies for the rather minimal site design, hopefully it's the 
> content that
> matters!)

Thanks for the info and very informative blog post.

> 
> Checkouts don't do exactly what you ask; you do have to update to tip of 
> the
> trunk before you can commit.  I can see how with a high commit rate that 
> may be
> an annoyance.  I can also see how developers committing branch states 
> they've
> never run the test suite on could be an annoyance, however  ;)

The problem for us is that we have a large C++ application and, as you 
probably realise, C++ is a not a good language for large projects due to 
its primitive methods of determining dependencies based on the file 
timestamps. When one header file is modified it can take between 5 and 
10 minutes to compile the project again. By the time the developer has 
recompiled he is most likely out of date with the trunk again (usually 
we have a commit to trunk every few minutes). This is why svn's approach 
is quite nice for us. We don't have to be at the tip of the trunk in 
order to commit as long as 2 developers have not touched the same file 
(which does not happen nearly as often).

I guess what I was hoping we could do with bzr is something like:

bzr merge developer-branch trunk-url

to merge a developer's branch into the trunk. The merge would be 
successful if there were no conflicts on the trunk. If there were then 
the developer would be informed and he would have to merge the trunk 
into his branch, resolve the conflicts, and then merge back to trunk as 
above.

I thought that with the smart server the changes sent by the merge to 
trunk would be sent as bundles, and the server could perform checks 
(like no conflicts, compiles, passes test cases), send out emails on 
successful merge, and so on. Is this a planned feature or is some of it 
already possible?

> 
> You could pretty easily write a plugin that automatically does an update 
> and
> commit in a single command, I think.  That might be a good enough 
> solution to
> the annoyance.
> 

But this would cause the developer to need a long recompile cycle when a 
header file is modified due to the update so I'm pretty sure this 
solution would not be feasible for us.

> An alternative would be to have each developer have seperate branches, 
> and the
> shared trunk merged via something like PQM.  The Launchpad development 
> team uses
> this process.  Steve Alexander describes the basic workflow in an email 
> here:
> http://mail.python.org/pipermail/python-dev/2005-August/055376.html, 
> it's a bit
> out of date (at the time Launchpad was using the Arch-based Baz 1.x, 
> which is a
> rather different beast to bzr), but the basic concept is the same. 
> Developers
> push a mirror of their branch to a common server, and submit a request 
> to the
> PQM bot to get it attempt the merge from that mirror.

This sounds like a good idea. I guess PQM can be configured so that it 
sends out email notifications to developers on successful merges? Is it 
possible to automate  this so that a push to the mirror and request to 
PQM is sent when the developer commits to his local branch?

> 
> This deals with the high commit rate issue by making merges to trunk
> asynchronous.  Additionally, the Launchpad PQM is configured to do a "make
> check" before accepting a commit.  Again, because of the asynchrony, it 
> doesn't
> matter much if a commit happens 1 hour later (because there's another 
> request
> already in progress, and you have a slow test suite), because the developer
> isn't stalled waiting for the trunk to be free to do their commit, and they
> aren't stalled on doing other work (they can always make a new branch of 
> the one
> waiting to be merged and start hacking on that straight away; it's a 
> distributed
> VCS after all).
> 
> You could in principle make PQM accept bundles as you suggest, but I 
> don't think
> that's been written yet.  A simple "star-merge /path/to/branch" works 
> fine for
> us.
> 
> Anyway, this is all entirely independent of the smart server, at least 
> in its
> current form.  It's likely that a future smart server will allow 
> configuring
> pre- and post-commit hooks on the server, but at the moment it's 
> basically a
> slightly faster alternative to the other remote transports like SFTP or 
> HTTP.
> The plans for it are simply to make it much faster, rather than to make 
> bzr work
> fundamentally differently.  Changing bzr to better support a particular 
> workflow
> is something that should be independent of any particular transport.

I agree. It would be nice if the smart server could be configured so 
that it can offer more checks than the dumb file storage but not to 
change the fundamental way that bzr would be used by the user.

Thanks again for your informative reply. I'm still not sure what the 
best model for us will but I hope we can find something suitable. It 
seems like bzr supports most styles of workflow but I need to determine 
the right one for us before recommending a switch away from svn. The 
smart merging of bzr would be a big help to us as well as rename 
support. We also don't like that in svn the person that merges a branch 
to trunk becomes the owner of those changes even if they were made by 
different developers. Bzr would solve all of these problems for us, as 
well as offering off-line commits so we are certainly very interested in 
switching. I just hope I can find a workflow model that will be accepted 
by my colleagues.

Regards,

Nicholas Allen