Describe your workflow

[Spencer Chastain]

We recently moved my development team (~10-14 core developers, many internal
customer user/developers, distributed across multiple sites) to bzr.

We have a shared repository created per site, with a primary site mirroring
our mainline integration branch to other sites.
Right now we use a cron job to push+update nightly for mirroring.  It'd be
nice if there was a single command for this task that the mainline
integration engineer can use at his option.

Developers are encouraged to branch per feature within their site's shared
repo - some opt to work on their personal machines.  The only restrictions
we make here is a branch naming convention - mostly to ease sorting out what
branches are stable for customer use and/or released and which branches are
feature development.

Our project regularly requires that you be testing on multiple machines at
once - and not all test machines have access to the same filesystems.  So we
encourage our developers to make use of checkout in this case, though I'm
wondering if a pull/up-load system may work better.  There does seem to be
some level of unneeded overhead when you want to keep 2 branches synched.
Trying to educate my developers on what they're doing and why they're doing
it seems ... overburdensome.  It's an easy concept, it should be an easy
use-case.  Maybe I'm missing something.

Occasionally developers get pulled in to lend a hand with another
developer's feature/bug.  In these cases, the primary/original developer
creates a treeless branch and everyone will work on personal a checkout
against that.  Once the primary developer's hurdle has been jumped, the
check-out is closed to the other developers (i.e. permission changes).
We're very touchy about how many changes go into a patch and who's
responsible, and checkouts seem to easily grow feature and change wise.

When a feature is complete and/or ready for testing, a patch is created and
placed in a change control system.  Integration engineers merge the patches
into the mainline, test the patch for readiness, and commit/release or
revert/reject as appropriate.  Developers are expected to merge against the
mainline integration branch as appropriate - at a minimum, they must merge
prior to submitting a patch.  More regularly is encouraged.  Developers can
merge other feature changes in early at their discretion.

Our project tree looks like this:
build-name/
+ ada/
+ cpp/
+ java/
+ makefile
+ MakeSupport/
+ mdbXmlRepo/
+ platforms/
+ scripts/
+ xml/

The build-name is either a build id or a development feature name.

Most of the time, people don't need the entire tree, but we decided it was
more important to track changes to the project as a whole than it was to try
to track the different parts of the project.  The inability to do partial
checkouts is cumbersome.  For some sister projects, this inability is a deal
breaker.

My workflow pretty much encompasses all of the above.  Depending on what I'm
doing - development, review, assistance - and who I'm working with tends to
keep things not exactly consistent.  But as a general rule, I always work
from my main machine, keep a pulled copy of integration local, branch
locally per feature, push then checkout to a branch on the shared
repository, bind to the remote branch, and manage between local and remote
as necessary.  Complicated?  Yes.  Does Bazaar make things easier?
Absolutely.  I just cannot begin to tell you the nightmare this was before
Bazaar.  Bazaar gives me confidence and speed in my development and revision
control that I simply did not have prior to this.

To be honest, I like the workflow (or somewhat lack thereof) a lot - because
it's something that I can continually adapt to my immediate needs.  But I'll
be the first to admit that it is a bit ... complicated.  I do think it could
be made simpler - specifically, keeping two branches in synch.  Making this
simpler would make the lives of some of my developers simpler as well.

So - that's the workflow of my team and myself.  I hope it provides some
useful information.

--Spencer


On Wed, Jun 25, 2008 at 8:50 PM, Martin Albisetti <argentina at gmail.com>
wrote:

> On Wed, Jun 25, 2008 at 9:32 PM, Colin D Bennett <colin at gibibit.com>
> wrote:
> > I have attached my loggerhead.conf.  Perhaps I have things configured
> > wrong.  My repository is owned by the 'bzr' user, who loggerhead is
> > running as.
>
> Could you check if "/bzr/.bzr/loggerhead-files" exists, and if it has
> a "filechanges.sql" file in it?
>
> If it doesn't, can you make sure you have python-sqlite installed, and
> maybe add the cache path to each individual branch on loggerhead.conf,
> in addition to the project?
>
> It should work perfectly fine with that size branch and hardware, so
> we're clearly missing something (probably the cache is not being
> generated).
>
>
>
> Cheers,
>
>
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080625/7921f67b/attachment.htm