From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Sun, 03 Jan 2010 00:30:44 +0900 Message-ID: <87oclcmsm3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87bphengwq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y6khmand.fsf@uwakimon.sk.tsukuba.ac.jp> <83skaoeutl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1262445720 31123 80.91.229.12 (2 Jan 2010 15:22:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 15:22:00 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 16:21:52 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NR5nX-0000EA-SQ for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 16:21:52 +0100 Original-Received: from localhost ([127.0.0.1]:39776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NR5nY-0002gV-2e for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 10:21:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NR5mk-0002M8-Of for emacs-devel@gnu.org; Sat, 02 Jan 2010 10:20:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NR5mg-0002KN-OX for emacs-devel@gnu.org; Sat, 02 Jan 2010 10:20:58 -0500 Original-Received: from [199.232.76.173] (port=40721 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NR5mg-0002KC-FT for emacs-devel@gnu.org; Sat, 02 Jan 2010 10:20:54 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45940) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NR5md-00050h-NV; Sat, 02 Jan 2010 10:20:52 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 23617820E; Sun, 3 Jan 2010 00:20:43 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B48181A33D7; Sun, 3 Jan 2010 00:30:44 +0900 (JST) In-Reply-To: <83skaoeutl.fsf@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119278 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Date: Sat, 02 Jan 2010 12:46:30 +0900 > > Cc: Emacs developers 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 =D3scar 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 =3D 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 >=20 > 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.) =20=20 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: >=20 > Purpose: Create a new checkout of an existing branch. >=20 > 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.