Re: Installing changes from branches

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 17:41:59 +0200
> 
> Yes. After the `bzr pull --overwrite' the quickfixes branch becomes
> identical to `trunk'. Hopefully, for quick fixes the local history is
> not something so valuable that you want to keep it around. Furthermore,
> a quick fix is usually made of a single commit, so you end mapping your
> local commit on `quickfixes' to a single commit on `trunk', which
> lessens the history loss.

If the fix takes only one commit, IMO it doesn't deserve a separate
branch.

FWIW, I have two kinds of branches that I use in different workflows:

  . A feature branch, where I work on some really non-trivial
    feature.  The bidi branch is a good example.  This kind of branch
    lives for a relatively long time, and is not necessarily removed
    when a feature is delivered (a.k.a. ``landed'') on the trunk --
    because the delivery may very well be in several stages.

    On this kind of branch, I merge back from the trunk as soon as I
    deliver a feature to the trunk.  Then I continue working on that
    branch, until the next delivery.

    The history of this kind of branch is very precious for me, and I
    never want to lose it.

  . A testing branch, where I test various small changes and features
    before installing them on the trunk.  The workflow on this kind of
    branch usually goes like this:

      cd ../test
      bzr merge --pull
      [hack away, test, hack some more, until ready to go public]
      bzr diff > ../foo
      cd ../trunk
      bzr up
      patch < ../foo
      bzr ci -m "whatever"
      [re-sync the branch with he trunk, be ready for the next hack]
      cd ../test
      bzr revert
      bzr merge --pull

    As you may have guessed, the history on this branch is not
    important at all, once I deliver the changes to the trunk.

    And no, I don't consider use of `patch' outside of bzr a sign that
    something is wrong.