[RFC] tortoise implementation design

[Sylvain Rouquette]

is there an ETA for an upcoming release (alpha/beta) ?

On Tue, May 20, 2008 at 6:38 AM, Eugene Wee <crystalrecursion at gmail.com> wrote:
> 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.
>
>



-- 
-= Syl =-