Re: Workflow to accumulate individual changes?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Sat, 02 Jan 2010 12:46:30 +0900
 > > Cc: Emacs developers <emacs-devel@gnu.org>

Urk, I'd been working in Mercurial and mixed semantics.  (I really,
really hate the way all the DVCSes insist on using each others'
command names and features but with different semantics attached to
the same name.)  I think Óscar got it right, though.  After testing,
this should be revised as below

 > > bzr branch trunk build-test

A lightweight checkout is often recommended here instead of branch:

    bzr checkout --lightweight trunk build-test

It's more efficient.

 > > cd build-test
 > > make bootstrap
 > > make test                 # if you like, but should be OK :-)
 > > for i = 1 2 3; do
 > >   cd ..
 > >   bzr branch trunk fix$i
 > >   cd fix$i
 > >   # hack
 > >   bzr commit -m "fix$i"
 > >   cd ../build-test

Oops, this is where I went WRONG:

 > >   bzr checkout ../fix$i

RIGHT:

bzr switch ../fix$i

 > >   make                    # Look Ma, no 'bootstrap'!
 > >   make test
 > > done
 > 
 > What is the semantics of "bzr checkout ../fix$i" in this case?  What
 > does it do, exactly?

(Checkout in fact will error here, or perhaps produce a fix$i subtree.
Not what you want.)

"bzr switch fix$i" says

    Purpose: Set the branch of a checkout and update.
    Usage:   bzr switch TO_LOCATION

    Options:
      --force              Switch even if local commits will be lost.
      -v, --verbose        Display more information.
      -q, --quiet          Only display errors and warnings.
      --usage              Show usage message and options.
      -b, --create-branch  Create the target branch from this one
                           before switching to it.
      -h, --help           Show help message.

    Description:
      For lightweight checkouts, this changes the branch being
      referenced.  For heavyweight checkouts, this checks that there
      are no local commits versus the current bound branch, then it
      makes the local branch a mirror of the new location and binds to
      it.

# In informal terms, the above says "this workspace now refers to the
# new branch for VCS information."

      In both cases, the working tree is updated and uncommitted
      changes are merged. The user can commit or revert these as they
      desire.

# The update happens automatically and immediately upon "bzr switch".
# In the workflow described above, the "uncommitted changes" are the
# build products generated by "make bootstrap", "make", and "make
# test".  In this workflow, no commits should ever happen in this
# tree; it is purely for the convenience of testing since you will
# have a usable bootstrapped tree.  (Of course if the changes from
# branch "fix1" to branch "fix2" would have broken the build and need
# a new "make bootstrap" under CVS, you'll need that here, too.)
  
      Pending merges need to be committed or reverted before using
      switch.

# The workflow described above should have no pending merges in this
# tree.  The only VCS operation you do here after initialization is
# "bzr switch", which is sort of like "cvs update -r" for this workflow.

      The path to the branch to switch to can be specified relative to
      the parent directory of the current branch. For example, if you
      are currently in a checkout of /path/to/branch, specifying
      'newbranch' will find a branch at /path/to/newbranch.

# Don't you just love DWIM?

      Bound branches use the nickname of its master branch unless it
      is set locally, in which case switching will update the the
      local nickname to be that of the master.

# I don't know what the above means, exactly; I don't use nicknames.

 > Bazaar docs are not very clear on that, to say the least:
 > 
 >     Purpose: Create a new checkout of an existing branch.
 > 
 > But fix$i is already an existing branch, and one with local changes,
 > so this ``create'' seems not quite the right word here.

My bad, I did warn that my syntax might be wrong.

 > (Btw, note the tricky convention regarding slashes, not for the faint
 > of heart IMO.)

Heh.  Emacsen users should be used to such things, though.