[RFC] tortoise implementation design

[Eugene Wee]

Hi Mark,

Mark Hammond wrote:
> In the meantime, I've been chatting with Alex Haro (who did the current tbzr
> implementation) and he created a new team
> (https://launchpad.net/~tortoisebzr-developers) and our current thinking is
> to create a team branch and work from that.  I'm a little concerned though
> that using a team branch implies we can't (or are discouraged from) making
> local branches, and instead should perform a checkout.  My lack of bzr
> experience is letting me down again, so I thought I'd ask for some advice
> here: are there recommendations for how to best manage the code for this
> work?  Maybe I should create a personal branch to work from, and the team
> branch is merged to only when stable?

This is what Ian Clatworthy recommended to me in March after I pointed 
out (in January :P) what I perceived as a mistake in the user documentation:

"Another way, and perhaps the one I ought to be
recommending (?), is to commit to a checkout of the shared mainline.

The key point is that the work, and incremental commits, are done in a
separate branch. When ready, that work is then merged+committed to the
shared mainline. Here's a concrete example ...

A project's tip is revision 100. A developer branches from it to make
changes. He makes 4 commits in his local branch. When ready, he merges
his changes into a checkout and commits.

Assuming no one else has committed anything, running 'bzr revno' on the
shared mainline shows 101. In comparison, if 'push' had been run
directly from the work branch instead of a merge+commmit, 'bzr revno'
would show 104.

The difference mightn't seem a big deal to some but it is IMNSHO. If all
developers simply push from work branches, then the mainline ends up
looking just like a traditional CVS/SVN one - heaps of uninteresting
(from the global perspective) commits with occasion ones representing a
known good state. By merging and committing as suggested, the mainline
is meaningful, bzr log --short is useful for viewing the big picture, an
item of work can be easily backed out if required and continuous
integration tools can trigger off mainline (only) changes."

I have successfully used this with my most recent (university) project 
and like my experience with it. You could have a personal working branch 
for each feature under development and publish your branch if necessary.

Regards,
Eugene Wee

P.S.: If I sent this twice because the first message to the list was not 
cancelled... whoops, still getting used to working with two Gmail 
accounts: one for personal mail an another for computing related mail.