Describe your workflow

[Spencer Chastain]

Well, I wouldn't think of them as two branches per se'.  I mean, granted, I
know that's how we who are familiar with the tool think of them, but the
developers I'm working with want to think of them as A and A-remote with the
understanding that there's perhaps a little lag between them in terms of
revision history.

I think what gets them is doing an update after they push/commit to a remote
branch.

So, to walk through their work flow:
- they branch on their windows machines and do development
- they need to do testing now against testing servers, so they push their
branch to a remote server.
- they then do a checkout on the remote branch to build the working tree (I
think upload will fix the confusion and angst push causes them)
- they then compile their code and begin server-client testing
- they then bind their windows branch to the remote server's branch
- during testing, they decide they need to tweak server side code, so they
change and commit code on the remote branch
- now they need to make corresponding client changes, they change and commit
-- oops! update first, then commit
- they're working back on the server and they want to see some client side
changes they made ... but waaaaiiiiit ... it's not there.  panic ensues,
panic ensues ... oh yes, I need to update the remote branch.
- repeat

It could be that they're still new, but I do think too that this could be
easier.  I just don't think the general use case is that I'm pushing a
branch just to copy the revision history.  It should build the working tree
automagically and/or merge with the existing working tree automagically.

But things are what they are, and we cope.  And this is a world of
difference (i.e. a tremendously easier world) from what we had, so I'm happy
to go along with it.

--Spencer

On Thu, Jun 26, 2008 at 10:25 AM, Colin D Bennett <colin at gibibit.com> wrote:

> On Wed, 25 Jun 2008 22:19:15 -0400
> "Spencer Chastain" <sechastain at gmail.com> wrote:
>
> > We recently moved my development team (~10-14 core developers, many
> > internal customer user/developers, distributed across multiple sites)
> > to bzr.
> > [...]
> > 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.
> > [...]
> > 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.
>
> By "keeping two branches in synch", what do mean, specifically?
> Do you mean that you have two related branches (let's call them A and
> B), you make different commits to each branch, and then you want to
> merge the changes to A into B and the changes to B into A?
>
> Regards,
> Colin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080626/61227230/attachment-0001.htm