Bazaar NG workflow question

[Nicholas Allen]

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!)

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  ;)

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.

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

-Andrew.

Nicholas Allen wrote:
> Hi,
> 
> We are currently looking into using Bazaar-NG for our repositories. We 
> are very interested in the smart server that you are working on but have 
> a question regarding it.
> 
> Is it possible for multiple developers to push to the same server so 
> long as there are no conflicts? For example, 2 developers have branches 
> off the trunk and one developer pushes his changes to the smart server 
> and then the other developer decides to do the same. We do not want that 
> the second developer would have to merge the trunk back into his private 
> branch first before he can merge his changes into the trunk. Only if 
> there are conflicts with the first developer would this be needed. So 
> essentially the server accepts requests to merge in changes (would these 
> be bzr bundles?) into itself from the private branches and only if it 
> encounters a conflict while doing so will it ask that developer to merge 
> trunk to his private branch.
> 
> This would be similar to how svn will allow you to commit to the server 
> as long as you have not modified a file that has been modified on the 
> trunk.
> 
> The reason I ask is that we have a high commit rate on the trunk and 
> always having to keep merging the trunk into your branch before you can 
> push your changes to the trunk would be annoying.
> 
> I hope my question is not a stupid one. Bzr really looks like an amazing 
> VCS!
> 
> Thanks in advance,
> 
> Nicholas Allen
>