emacs-devel
[Top][All Lists]
Advanced

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

Re: GNU Emacs is on Bazaar now.


From: Giorgos Keramidas
Subject: Re: GNU Emacs is on Bazaar now.
Date: Tue, 29 Dec 2009 03:26:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (berkeley-unix)

On Mon, 28 Dec 2009 17:24:29 -0500, Karl Fogel <address@hidden> wrote:
>Andreas Schwab <address@hidden> writes:
>>Karl Fogel <address@hidden> writes:
>>> A separate question is, is this a *good* procedure for quick fixes?
>>
>> Just commit and push them.  There is no point in using a special branch.
>
> Andreas, have you read BzrForEmacsDevs?
>
> In the scenario there, 'trunk' is a bound branch.  So this would be
> only a 'commit', no need for a separate command to push.  (But I'd
> feel more comfortable if you checked over the entire procedure
> documented there, to make sure there are no other problems lurking in
> the wings if one uses the 'trunk' branch, as currently set up, for
> direct development of quick fixes.)

One of the things that seem annoying when people make small changes
using a DVCS is the merge step that is required if the remote trunk has
already moved on.  It seems silly to have merge commits for tiny and
simple commits that modify a few lines in one place.  The inevitable
"merge pollution" of the branch history can be avoided most of the time
by 'rebasing' the changes inside the quickfixes branch before pulling
them into the trunk.

The 'rebase' plugin of bazaar[1] may help a lot with this sort of
workflow.  Using this plugin one can keep making small changes in the
quick fixes, testing them outside of the bound 'trunk' copy and then
pulling into the local & bound trunk when they are done, FSVO "done".

[1] http://wiki.bazaar.canonical.com/Rebase

Installing and using the rebase plugin is easy on UNIX.  One can start
by making a ~/.bazaar/plugins directory and copying the rebase plugin
itself inside it:

    $ mkdir ~/.bazaar/plugins
    $ cd ~/.bazaar/plugins
    $ bzr branch http://people.samba.org/bzr/jelmer/bzr-rebase/trunk rebase

This will install and make visible a few new commands:

    $ bzr help commands | grep '^rebase'
    rebase                  Re-base a branch. [rebase]
    rebase-abort            Abort an interrupted rebase. [rebase]
    rebase-continue         Continue an interrupted rebase after resolving
    rebase-foreign          Rebase revisions based on a branch created with a
    rebase-todo             Print list of revisions that still need to be 
replayed
    $

Now small changes can be committed to the quickfixes branch as described
in BzrForEmacsDevs.  When the small change is committed to 'quickfixes',
we can now:

  * Pull any trunk changes from savannah

        $ cd ../trunk
        $ bzr pull

  * Go back into the 'quickfixes' branch and rebase the small change on
    top of the latest local trunk (which should be up-to-date with the
    savannah copy of the same branch now):

        $ cd ../quickfixes
        $ bzr rebase

If all goes well the local change of 'quickfixes' will be rebased on top
of the trunk, eliminating the need of "bzr merge" for such a small
commit.  In this case bazaar will report something like:

    Committing to: ~/bzr/emacs/quickfixes/
    modified lisp/foo.el
    Committed revision 105601.

If there are conflicts, rebase will temporarily stop and leave conflict
markers in the files that require manual intervention.  After editing
the files and resolving the conflicts, one can run:

    $ bzr resolve lisp/foo.el
    $ bzr rebase-continue

I personally find this sort of workflow a bit useful when dealing with
tiny changesets.  The final branch history of trunk is going to be much
"cleaner" if we don't have thousands of tiny changesets followed by a
merge commit after each small one.  But this is just a personal choice
and it is heavily influenced by my experience with changeset rebasing in
other DVCS's.





reply via email to

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