Received: from spf1.us4.outblaze.com (spf1.us4.outblaze.com [205.158.62.23]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id iB71D7sV029241 for ; Tue, 7 Dec 2004 01:13:07 GMT Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by spf1.us4.outblaze.com (Postfix) with ESMTP id 61CF053963 for ; Tue, 7 Dec 2004 00:31:39 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CbTQH-0000OC-0T for migo@homemail.com; Mon, 06 Dec 2004 19:41:45 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CbTPs-0000O6-RH for gnu-arch-users@gnu.org; Mon, 06 Dec 2004 19:41:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CbTPs-0000Nu-DG for gnu-arch-users@gnu.org; Mon, 06 Dec 2004 19:41:20 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CbTPs-0000Nr-9z for gnu-arch-users@gnu.org; Mon, 06 Dec 2004 19:41:20 -0500 Received: from [194.217.242.90] (helo=anchor-post-32.mail.demon.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CbTFt-0001iV-BW for gnu-arch-users@gnu.org; Mon, 06 Dec 2004 19:31:01 -0500 Received: from cenderis.demon.co.uk ([62.49.17.254] helo=localhost) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1CbTFs-000AJU-77 for gnu-arch-users@gnu.org; Tue, 07 Dec 2004 00:31:00 +0000 Received: by localhost (Postfix, from userid 1000) id C7FA57C693; Tue, 7 Dec 2004 00:30:59 +0000 (GMT) To: gnu-arch-users@gnu.org Subject: Re: [Gnu-arch-users] Re: Arch Versus CVS Versus Subversoin References: <20041205000613.PNEI7152.lakermmtao09.cox.net@nonerjsnum1tkq> <26E1F314-4654-11D9-AD55-000A957659CC@spy.net> <20041205023828.GA11443@suffields.me.uk> <87pt1o9kvb.fsf@tleepslib.sk.tsukuba.ac.jp> <200412061850.iB6IoWmS036469@xl2.seyza.com> <87brd7428y.fsf@deneb.enyo.de> <878y8bjgre.fsf@cenderis.demon.co.uk> <873byjjdxz.fsf@cenderis.demon.co.uk> <41B4DE41.3070907@arbash-meinel.com> From: Bruce Stephens X-Hashcash: 1:22:041207:gnu-arch-users@gnu.org::4BiWrvB9/4q8Sarr:00000000000000000000000000000000000000043OW Date: Tue, 07 Dec 2004 00:30:59 +0000 In-Reply-To: <41B4DE41.3070907@arbash-meinel.com> (John A. Meinel's message of "Mon, 06 Dec 2004 16:33:37 -0600") Message-ID: <87d5xnhruk.fsf@cenderis.demon.co.uk> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: gnu-arch-users@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: a discussion list for all things arch-ish List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org Status: RO Content-Length: 2618 Lines: 64 John A Meinel writes: > Bruce Stephens wrote: [...] > Actually, on the arch-dev list we discussed quite a bit how the > current archive format could easily support faster annotations. And I > have to say, it depends on your usage. Very much so, yes. > I have never used annotate seriously (only, hey that's kind of > neat), but I've run star-merge at least hundreds of times. For some > people the opposite would be true. Indeed. I've read comments by people who just don't care about history beyond a few months, and that seems reasonable for some environments. But at work we regularly want to look at code several years old and fix problems people are having with it, and often that involves applying some set of patches (because we've fixed it in the current branch) to the old code. (Of course, that doesn't require annotate (I've also very rarely used annotate), but it almost always requires looking at the code of various revisions. Better than annotate would be some function-based annotation tool (showing where some function had been changed), as promised by some of the papers in the Stellation project, but the code that's available doesn't yet do that.) Presumably that's not an uncommon environment: the Debian security team often backports bugfixes rather than upgrading packages. I'm not saying they're desperate for a dancy version control system, but that seems like the kind of activity that's worth supporting: partly that's star-merge and cherrypicking and things, but partly it's providing ways of looking at old code and exploring changes in it. > It is possible to make both fast. Absolutely, yes. > Trying to create a server that used xdelta internally would be a > little bit painful, but you are completely right, it would be > possible. Just not really worth creating a new wire protocol, and > all the rest of the headaches. A new wire protocol isn't absolutely required, just some kind of a smart revision library that can produce file revisions (and probably other things you want from the revision library like diffs and annotated files and things). On the other hand, once you've got that then you can reconstruct the archive, so an obvious option is to regard the revision library as primary, and generate the archive as necessary (indeed, Tom has suggested that kind of thing as a potentially interesting experiment). _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/