emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bzr repository ready?


From: Óscar Fuentes
Subject: Re: bzr repository ready?
Date: Mon, 23 Nov 2009 06:11:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Right now, the only question that's come up that I think belongs in that
>> document is "What should be the standard workflow for Emacs developers
>> in Bazaar?"  That's a question we already had a draft answer for, and
>> Stephen Turnbull has since improved it (I'm about to review it).
>
> Except that alternative workflows were mentioned here since then, and
> it is no longer clear to me that the one described on the Wiki is the
> best one.  Perhaps we should add a few more there.

There is no "best-one" workflow. It depends on what kind of work you do,
what's your environment (i.e. connected/disconnected) and even on your
personal preferences.

People like Richard that is off-line most of the time will appreciate
the possibility of committing lots of changes to his personal repo and
send them all to the GNU repo in one batch when he gets net access. This
has the inconvenience that you allow a lot of time for the branches to
diverge and the merge you are required to do before pushing your local
commits to the GNU repo can give a bit of work, on terms of code review.

Other people that work at home doing occassional small code cleanups and
fixing typos will be happy working with bound branches (aka heavyweight
checkouts) which sends their commits to the GNU repo on the spot.

Some people will like to organize their work on feature branches. Other
less-strict personalities will do all their work on the same branch.

It is not a matter of finding the best workflow, but beginning with one
that is better than CVS and simple enough to minimize the effort,
setting a basis for introducing variations.

On this regard, the workflow that Jason described elsewhere based on
bound branches is the one we should recommend, IMHO. Once you master
that, using unbound branches is an evolutive step: you need to learn
more, but what you already know still applies.

-- 
Óscar





reply via email to

[Prev in Thread] Current Thread [Next in Thread]