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,gmane.comp.version-control.bazaar-ng.general Subject: Re: Emacs Bazaar repository Date: Sat, 15 Mar 2008 09:00:27 +0900 Message-ID: <87prtwsvok.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205538744 6534 80.91.229.12 (14 Mar 2008 23:52:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 23:52:24 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org, Matthieu Moy , bazaar@lists.canonical.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 15 00:52:52 2008 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 1JaJhj-0005fy-EC for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2008 00:52:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaJhA-0006Bb-29 for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 19:52:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaJh6-0006As-4v for emacs-devel@gnu.org; Fri, 14 Mar 2008 19:52:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaJh4-0006AI-3D for emacs-devel@gnu.org; Fri, 14 Mar 2008 19:52:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaJh3-0006AA-Io for emacs-devel@gnu.org; Fri, 14 Mar 2008 19:52:09 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JaJgz-00009o-Hu; Fri, 14 Mar 2008 19:52:05 -0400 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 244E6800D; Sat, 15 Mar 2008 08:52:04 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 53F761A29EF; Sat, 15 Mar 2008 09:00:27 +0900 (JST) In-Reply-To: X-Mailer: VM 7.19 under 21.5 (beta28) "fuki" 2785829fe37c XEmacs Lucid X-detected-kernel: by monty-python.gnu.org: 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:92632 gmane.comp.version-control.bazaar-ng.general:38628 Archived-At: Eli Zaretskii writes: > Incidentally, why are we concentrating on "bzr log"? Partly because intuitively it "should" be fast, it's just a "cat" of the index file. But this isn't true for bzr, so people's expectations are contradicted. > is that a frequent operation? Yes. You need changeset IDs frequently for communicating with users and other developers, and for diffs. > With CVS, I find myself doing "cvs log" only once in a few months, > when I'm looking for a change corresponding to some ChangeLog > entry. I think that you will pretty quickly find that ChangeLogs as you know them have to be abandoned, because they cause merge conflicts at O(n^2) or so, where n = "rate of commits/unit of time". Also, most developers in projects using VCSes more recent than CVS use " log" a lot. A big problem is that ChangeLogs either have to be excluded from their changesets, or you can't include a changeset ID in the ChangeLog entry corresponding to the changeset. (IDs are secure hashes and thus you must solve a fixed-point problem for a secure hash function if the ChangeLog containing the ID is part of the changeset!) > Aren't "push" and "pull" much more important, as far as speed is > concerned, for everyday work? In theory, yes. In practice, no. They're done sufficiently often that (with the possible exception of Darcs) all recent VCSes are net-lag-bound because users won't put up with speed issues for local repos. In practice these also only have "big O" problems when you're pulling an old and active branch for the first time, which is acceptable if success is guaranteed. (Another problem with bzr, as we've seen -- a long pull is likely to fail because the requested archives may disappear before they get shipped out the wire. This is probably a configuration issue with Jason's repo, typically there are parameters you want to tweak for public repos vs private branches.) > Also the equivalent of "cvs diff", I think. With the exception of Darcs (which can be O(r1 - r2)), all modern VCSes do this quickly. > Those are the ops I use much more frequently than "log" and "annotate". I use both fairly frequently, and it's very annoying to me when they take more than 5 seconds or so. YMMV of course.