[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Workflow to accumulate individual changes?
From: |
Stephen J. Turnbull |
Subject: |
Re: Workflow to accumulate individual changes? |
Date: |
Sun, 03 Jan 2010 00:30:44 +0900 |
Eli Zaretskii writes:
> > From: "Stephen J. Turnbull" <address@hidden>
> > Date: Sat, 02 Jan 2010 12:46:30 +0900
> > Cc: Emacs developers <address@hidden>
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.
Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
Re: Workflow to accumulate individual changes?, Alfred M. Szmidt, 2010/01/01
Re: Workflow to accumulate individual changes?, Alfred M. Szmidt, 2010/01/01