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: bzr repository ready? Date: Wed, 25 Nov 2009 14:28:57 +0900 Message-ID: <87iqcz5g12.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <87zl6fnnu2.fsf@notengoamigos.org> <87aaye3nba.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5rqm7gm.fsf@notengoamigos.org> <87skc5spso.fsf@uwakimon.sk.tsukuba.ac.jp> <87ws1hujh5.fsf@notengoamigos.org> <4B0B1DA6.7030206@harpegolden.net> <87k4xgrdsl.fsf@canonical.com> <4B0B34AF.20400@harpegolden.net> <87my2cptji.fsf@uwakimon.sk.tsukuba.ac.jp> <4B0C6F19.4000200@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259126639 13701 80.91.229.12 (25 Nov 2009 05:23:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2009 05:23:59 +0000 (UTC) Cc: es , Eli Zaretskii , Karl Fogel , Jason Earl , emacs-devel@gnu.org To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 06:23:51 2009 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 1NDAM1-0007nX-Qi for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 06:23:50 +0100 Original-Received: from localhost ([127.0.0.1]:34482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDAM1-0004Yk-8y for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 00:23:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDALS-0004I1-Sc for emacs-devel@gnu.org; Wed, 25 Nov 2009 00:23:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDALN-0004Ep-T4 for emacs-devel@gnu.org; Wed, 25 Nov 2009 00:23:14 -0500 Original-Received: from [199.232.76.173] (port=48622 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDALN-0004Eh-Nf for emacs-devel@gnu.org; Wed, 25 Nov 2009 00:23:09 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:43294) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDALI-0001Zs-E9; Wed, 25 Nov 2009 00:23:04 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id F3E081535A8; Wed, 25 Nov 2009 14:22:58 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 555F71A2907; Wed, 25 Nov 2009 14:28:57 +0900 (JST) In-Reply-To: <4B0C6F19.4000200@harpegolden.net> 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:117730 Archived-At: David De La Harpe Golden writes: > > You don't commit any local changes, because you didn't make any in > > that branch. You *merge* local changes to it from your working > > branch, > > well, to the working tree of branch trunk, not to the branch as such? Uhm ... you're comparing with git merge, which commits-unless-conflict? That's right, a "bzr merge" is entirely VC-data-to-working tree (you can do it from a branch or a specially-formatted merge directive file) operation, and doesn't automatically commit. My point was that the commit in the suggested workflow is based on VCS data, and therefore reversible and recoverable. It's not based on user changes, which would be irrecoverable if you did something like "bzr pull --overwrite". The whole suggested workflow is designed with two principles in mind: 1. A user shall not be asked to choose between committing the content of his workspace and getting an update from upstream. 2. The default view presented by "bzr log" shall be the list of the user's commits in his workspace, and the list of contributions (each of which may contain a long sequence of commits) in the upstream master and its mirrors. I don't really care, but no. 2 is a feature that people who like Bazaar love until the fur comes off. Caveat: in the above, I'm speaking for myself, not for Karl. > > and these are *automatically* passed on to the upstream master > > when you commit. > > So hybrid of D and non-D VCS. I suppose that's why "bound branch" was > "checkout", it was by an analogy to non-D VCS where a cvs commit > goes off to the remote server. Yes. And that analogy is even closer with "checkout --lightweight", which is why the terminology (and the default) is moving in that direction. > What happens when you commit "on" a bound branch without network > connectivity? I guess it just fails, since you're not really > committing to the bound branch but rather to the associated remote > upstream branch? Yes. If you know you're disconnected, you can do "bzr commit --local". As Stefan mentioned in passing, there are some issues with this. I don't know whether it's in the implementation of Bazaar or in the implementation of Stefan ;-), but if it's the latter, I'm sure you're aware that that implementation is quite advanced and robust, so this feature is hard to use. :-) > > Because it's pointless to do that. The race condition in using > > my-trunk (not bound to upstream master) means that you can succeed in > > committing the merge, but fail the push. > > Well, I suppose in the git world one just tends to avoid many > committers in the first place (since given DVCS there's no actual > need for much shared access beyond perhaps some redundancy), That's false. Decentralized project workflows like Emacs's do need it. The more centralized single-maintainer and gatewayed project architectures (a la the well-known punk code artists "Linus and His Lieutenants") don't, of course, but distributed VCS supports a wide variety of workflows. Be that as it may, the current proposal AIUI is to emulate the current CVS-based *project-level* workflow as closely as possible. Individuals with experience with dVCS are welcome to vary their own workflows as they please, but as you will observe in this thread rms and Eli Z are (to a greater or lesser extent personally) concerned with workflow disruption, and Stefan has explicitly indicated that at first minimizing disruption is a goal (sine qua non?) > and the occasional conflict isn't the end of the world. Maybe it's > easier to rewrite history in git though, I know nothing of bzr > (though I did just find bzr rebase) Much easier! Don't rewrite history in Bazaar. It's very limited, painful, dangerous[1], and worst of all :-) you will be treated as a pariah by many in the Bazaar community. Footnotes: [1] It's non-trivial to recover an obsoleted head. No reflogs, no documentation of the commands needed to find heads.