From infrastructure-dev-return-429-apmail-infrastructure-dev-archive=apache.org@apache.org Thu May 01 18:37:05 2008 Return-Path: Delivered-To: apmail-infrastructure-dev-archive@locus.apache.org Received: (qmail 95363 invoked from network); 1 May 2008 18:37:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 May 2008 18:37:04 -0000 Received: (qmail 52065 invoked by uid 500); 1 May 2008 18:37:06 -0000 Delivered-To: apmail-infrastructure-dev-archive@apache.org Received: (qmail 52009 invoked by uid 500); 1 May 2008 18:37:06 -0000 Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: infrastructure-dev@apache.org Delivered-To: mailing list infrastructure-dev@apache.org Received: (qmail 51997 invoked by uid 99); 1 May 2008 18:37:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 May 2008 11:37:06 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of santiago.gala@gmail.com designates 72.14.220.159 as permitted sender) Received: from [72.14.220.159] (HELO fg-out-1718.google.com) (72.14.220.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 May 2008 18:36:11 +0000 Received: by fg-out-1718.google.com with SMTP id e21so756631fga.29 for ; Thu, 01 May 2008 11:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=4TPAbEjpHz9eBmwxvzpU/jYZNzeZUJ2hP2Kcm5rpOi4=; b=Asi73inH/4wczayoKMFIvFqeP0KPqbHWNFq1/rlCyE/9cgRj3OTGbfheupPdnUPtRaprDo7A9zFLjV8ZWJEBnJZYz1V8+tX2YY3uMFB0a7DK+c43hZZR1cKDEU0tjs8Yt9mzIexDUm03LoJrmFzmDoh3Hy/T95dYlIhRS1ZbeXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=nUi1ECsttd5G9RUBjOyHvfTEIhTmD13r/ZUQL5UuIIjKudlI8heFAQrA/dJbtvpH6WTrT2oVrG0m8Roe29+LEeeA0yQsr0fl2zmLWrwgOZZGKGH5CwXhYkDpjzBEqNF4qjCF/PWKlIPGrqbGTqj2T426Qz4yOtSzxac2bdebwEY= Received: by 10.86.28.2 with SMTP id b2mr1802653fgb.78.1209666991917; Thu, 01 May 2008 11:36:31 -0700 (PDT) Received: from ?172.27.70.188? ( [81.33.31.233]) by mx.google.com with ESMTPS id 22sm3560062fkr.11.2008.05.01.11.36.30 (version=SSLv3 cipher=RC4-MD5); Thu, 01 May 2008 11:36:31 -0700 (PDT) Subject: Re: [dSCM] Use case: new committer From: Santiago Gala To: infrastructure-dev@apache.org In-Reply-To: References: <1209658190.5614.271.camel@marlow> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 May 2008 20:38:57 +0200 Message-Id: <1209667137.5614.280.camel@marlow> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org El jue, 01-05-2008 a las 19:30 +0200, Sander Striker escribió: > On Thu, May 1, 2008 at 6:09 PM, Santiago Gala wrote: > > I just wanted to launch a use case for a distributed SCM integration, > > including a concrete example. Just today, a new committer in shindig, > > committed a big chunk of code. This was because there were problems with > > his password and all together, he had almost one month delay from being > > accepted as a committer and being able to effectively commit. > > > > Instead of: one big commit of > > 120 files changed, 7404 insertions(+), 3790 deletions > > he could have committed the 20 tematic commiits that probably this work > > consisted of. Ha would have kept them (merging or even attaching to > > issue tracker items) all the work in nice logically related units until > > he had the ability to push this work forward to the common repository. > > There is nothing preventing you from not accepting a powerplant and > insisting on smaller changes. Yes, it's more effort to commit several > patches and to keep them apart, but this is what I've had to do in the > past as well to keep stuff I wanted to get in sane and reviewable. Could > a dSCM have been helpful in that. Maybe. Could I do it without? > Clearly so. Yes, tools are useful, this is all I meant here. I answer this point to Henning's email. > > Also, there is nothing preventing you from using svk or git-svn or > whatever other tool that respects the main svn repository as primary. > I really don't see why we need to invest in trying out another decoupled > repository using some other version control system, for which we need > to maintain separate authorization... To me, the use case above is > certainly not one to draw me over the line. But YMMV. Just realize that there is no line, and draw over yourself :) I mean, whatever floats each one's boats, as you said. Regards > > Cheers, > > Sander -- Santiago Gala http://memojo.com/~sgala/blog/