From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liu Yubao Subject: Re: two questions about the format of loose object Date: Tue, 02 Dec 2008 10:43:56 +0800 Message-ID: <4934A0EC.5010600@gmail.com> References: <493399B7.5000505@gmail.com> <7voczws3np.fsf@gitster.siamese.dyndns.org> <4933AE55.2090007@gmail.com> <20081201152148.GG23984@spearce.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Junio C Hamano , git list To: "Shawn O. Pearce" X-From: git-owner@vger.kernel.org Tue Dec 02 03:45:25 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1L7LGO-0007WV-85 for gcvg-git-2@gmane.org; Tue, 02 Dec 2008 03:45:24 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752952AbYLBCoF (ORCPT ); Mon, 1 Dec 2008 21:44:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752960AbYLBCoE (ORCPT ); Mon, 1 Dec 2008 21:44:04 -0500 Received: from ti-out-0910.google.com ([209.85.142.184]:57905 "EHLO ti-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752942AbYLBCoC (ORCPT ); Mon, 1 Dec 2008 21:44:02 -0500 Received: by ti-out-0910.google.com with SMTP id b6so1755181tic.23 for ; Mon, 01 Dec 2008 18:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=flYOW5qdpF3T8ewfvhts60lteLUyGhR0CawoR2GWi+U=; b=K7XcwY0snA2R15qSoWTVDWNBkVZI6wRuh9ag3qEEJIXzknCUPYt3fI3vb/oipkElIe DSxbQEDIwQuPTFD6Qkk8A+0rXVLQQo/9OZdG8wNaNF9RJu0icz8G4CTbcuRapB/KNKtW 7cwdn7DnT/h6Dxu0rZ/r40ip81WDJGTC0IPOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=c5aCMClGj1l1hM+HD3ZGG1LLBB8VoffgwPPZXgxdk2IpASRTPX/ZjUs795tObOE4m3 jNGVimyuOwP0wzZvzOGrcrYynJeo06Nk1QWKNbDRx6SOqSrzcaZAU/yDxBZ5nfmiDe9U RDJnwPV1rVYrPn5J2VjPJ7BZD0T4lXnJP/JPk= Received: by 10.110.86.3 with SMTP id j3mr2299005tib.4.1228185840174; Mon, 01 Dec 2008 18:44:00 -0800 (PST) Received: from ?10.64.1.142? ([211.157.41.194]) by mx.google.com with ESMTPS id 22sm2896166tim.7.2008.12.01.18.43.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 18:43:59 -0800 (PST) User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: <20081201152148.GG23984@spearce.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Shawn O. Pearce wrote: > Liu Yubao wrote: >> Thanks for your explanation, but I doubt if it's too costly to change the >> format of loose object, after all this doesn't change the format of pack >> file and affect git-pull/fetch of old git client. > > It is too costly; Jakub pointed out the dumb protocol clients > would have issues with the new format. Anyone copying a repository > between machines using scp or a USB memory stick may also run into > a problem. Etc. > Yes, exceptional case, is it acceptable that core.uncompressedLooseObject is set to false by default especially for NFS file system? >> Some cons and pros. >> >> cons: >> >> * old git client can't read loose objects in new format >> (People degrade git rarely and old git can read pack files >> generated by new git, so it's not a big problem) > > That's a pretty big con. We can also add slower performance on NFS, > as has been reported already by others. > I mean to add a format, not to replace the current format of loose object. >> pros: >> >> * avoid compressing and uncompressing loose objects that are likely >> frequently used when you are coding/merging > > True, loose objects are among the more frequently accessed items. > >> * share loose objects among multipe git processes > > Probably not a huge issue. How many concurrent git processes are > you running on the same object store at once? During development? > Its probably not more than 1. So sharing the objects doesn't make > a very compelling argument. > In my company we have a central server to host source code repository managed by git+ssh. Some collegues also work on the same machine (maybe not a good practice) and set alternates to the central repository, so there can be multiple git processes operating same git object database. In fact we have a wrapper script of git to make git fit our development process better because git's submodule support isn't good enough. One command in the wrapper script can execute many git commands in a short time. >> * the new code path is simpler although we will have more code paths for >> compatibility > > The new code path is more complex, because although one branch is > very simple (mmap and use) the other code paths have to stay for > backwards compatibility. Every time you add a branch point the > code gets more complex. It works well enough now, and is at least > one branch point simpler than what you are proposing. So I'm not > really interested in seeing the change made. > Could you review my patches sent just a moment ago? The key changes are rather small. Best regards, Liu Yubao