From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LWJ3n-00067Y-8K for garchives@archives.gentoo.org; Sun, 08 Feb 2009 23:27:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DA9B7E03D6; Sun, 8 Feb 2009 23:27:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B3D49E03D6 for ; Sun, 8 Feb 2009 23:27:32 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 28A866520C for ; Sun, 8 Feb 2009 23:27:32 +0000 (UTC) Message-ID: <498F6A7A.2060408@gentoo.org> Date: Sun, 08 Feb 2009 15:27:54 -0800 From: Zac Medico User-Agent: Thunderbird 2.0.0.19 (X11/20081209) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation References: <498758E6.5080609@gentoo.org> <1234045916.24784.1373.camel@localhost> <498E17E6.8060407@gentoo.org> <20090208221814.722f573a@snowmobile> <498F5FF5.50203@gentoo.org> <20090208224721.4193ca45@snowmobile> <498F64D4.4080303@gentoo.org> <20090208231010.4b2ebe3b@snowmobile> In-Reply-To: <20090208231010.4b2ebe3b@snowmobile> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3496a13e-831a-442f-b068-fb254b09cf1b X-Archives-Hash: 1c4ffa343c1d7e84ad3e314c76dc413f -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 08 Feb 2009 15:03:48 -0800 > Zac Medico wrote: >>> No, it's just encouraging bad development practices. >> It seems like you're making a rather arbitrary judgment. > > Not storing generated content under revision control is hardly an > arbitrary judgement. It's a well accepted software development bad > practice. In general, it's a good rule of thumb. However, in this case I think we have a justifiable exception to the rule. >>> If you're concerned that setting up an rsync mirror is difficult, >>> why not make a tool that generates a tarball, including metadata, >>> for a repo, and have people run that on a cron and distribute it >>> via http? That's just as easy to host, and anyone running an >>> overlay big enough to make this impractical already has the >>> resources to deal with rsync instead... >> I'm not saying that it necessarily "difficult" or "beyond the >> resources", but it does create an unnecessary burden. I think that >> it adds a significant level of convenience to be able to use a >> version control system as a single distribution channel. > > Which is offset and more by the massive inconvenience of having to > keep track of and store junk under version control. I think you're making it out to be worse than it really is. Like I said, I think we have a justifiable exception to the rule. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPankACgkQ/ejvha5XGaNpnQCfVHgDPmfzUbfH6mIgmpUxcWda xkYAoJ1s+DEd873rpRpDQkck6ZP7pclr =K88a -----END PGP SIGNATURE-----