From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Mackall Subject: Re: Mercurial vs Updated git HOWTO for kernel hackers Date: Tue, 28 Jun 2005 15:14:22 -0700 Message-ID: <20050628221422.GT12006@waste.org> References: <42B9E536.60704@pobox.com> <20050623235634.GC14426@waste.org> <20050624064101.GB14292@pasky.ji.cz> <20050624123819.GD9519@64m.dyndns.org> <20050628150027.GB1275@pasky.ji.cz> <20050628180157.GI12006@waste.org> <62CF578B-B9DF-4DEA-8BAD-041F357771FD@mac.com> <3886.10.10.10.24.1119991512.squirrel@linux1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mercurial@selenic.com, Petr Baudis , Linux Kernel , Kyle Moffett , Jeff Garzik , Git Mailing List X-From: mercurial-bounces@selenic.com Wed Jun 29 00:08:07 2005 Return-path: Received: from waste.org ([216.27.176.166]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnOEu-0006Re-IL for gcvmd-mercurial@gmane.org; Wed, 29 Jun 2005 00:07:33 +0200 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.4/8.13.4/Debian-3) with ESMTP id j5SMEOm4017283; Tue, 28 Jun 2005 17:14:29 -0500 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.4/8.13.4/Debian-3) with ESMTP id j5SMEMhf017276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2005 17:14:22 -0500 Received: (from oxymoron@localhost) by waste.org (8.13.4/8.13.4/Submit) id j5SMEMqp017273; Tue, 28 Jun 2005 17:14:22 -0500 To: Sean Content-Disposition: inline In-Reply-To: <3886.10.10.10.24.1119991512.squirrel@linux1> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new X-BeenThere: mercurial@selenic.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: mercurial.selenic.com List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mercurial-bounces@selenic.com Errors-To: mercurial-bounces@selenic.com On Tue, Jun 28, 2005 at 04:45:12PM -0400, Sean wrote: > On Tue, June 28, 2005 4:27 pm, Kyle Moffett said: > > On Jun 28, 2005, at 14:01:57, Matt Mackall wrote: > >> Everything in Mercurial is an append-only log. A transaction journal > >> records the original length of each log so that it can be restored on > >> failure. > > > > Does this mean that (excepting the "undo" feature) one could set the > > ext3 "append-only" attribute on the repository files to avoid losing > > data due to user account compromise? > > > > Probably. In Git, which is a bit more flexible than Mecurial you can > chmod your objects to read-only or use the ext3 immutable setting to > protect your existing objects. You can do this in Mercurial as well. > You can even have a setup where objects > are archived onto write-once media like DVD and still participate in a > live repository, where new objects are written to hard disk, but older > object are (automatically) sourced from the DVD. Have fun with that. It's an excellent way to destroy your DVD drive. Git's completely structureless filename hashing pretty much guarantees that disk layout will degrade to worst-case random access behavior over time. Just walking through the 2000 commit blobs in the current tree can take minutes cold cache on a fast hard disk. Walking the 1700 tree blobs in a given version takes quite a while too. Put that on a DVD and that could easily turn into hours of continuous seeking for a simple operation like checking out tip of tree. And as far as I know, ISO9660 and UDF don't really handle huge directories well. So if you try and put the whole kernel history (200k files, some huge number of directory blobs, and 30k-60k commit blobs) on a DVD, you'll be really hurting. Meanwhile the whole history (>30k changesets) with Mercurial fits on a regular CD, with reasonable directory sizes and I/O patterns. Not that it's really worth the trouble. It takes longer for me to burn an ISO image to disc than to download a complete kernel repo from kernel.org. -- Mathematics is the supreme nostalgia of our time.