From users-return-1058-daniel=haxx.se@subversion.apache.org Wed Feb 17 15:25:10 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o1HEP9bo001755 for ; Wed, 17 Feb 2010 15:25:10 +0100 Received: (qmail 67226 invoked by uid 500); 17 Feb 2010 14:25:04 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 67218 invoked by uid 99); 17 Feb 2010 14:25:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 14:25:04 +0000 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 andy.levy@gmail.com designates 209.85.219.215 as permitted sender) Received: from [209.85.219.215] (HELO mail-ew0-f215.google.com) (209.85.219.215) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Feb 2010 14:24:56 +0000 Received: by ewy7 with SMTP id 7so192954ewy.36 for ; Wed, 17 Feb 2010 06:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=51Fc6qAAp6ez85tES6E6QYQPvut+zovS9ddjvAsO5xc=; b=Tcyqvckere4zffCMeWEF+WouJZXdoMbOisDnCrJ1Ewi7OcWQ6oOFV6FafQ1q/BF139 OokSLagFrgSeYlXnoNxAGaMR+sTBU6LeF9/eVuiiufRY1jMkIrH47LWLUuzyifT6dQRZ RhGjg5MAhnxeb1pDX4RG9YjaJiFi8zppxhINM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DTyTPA/YqUnQCv8fj09OSHtG0eo8/3ZKTeiGuyCHdKnYBgm9bTsKHZhomHb9rAECOA rQiZK0F8GNsGlCWB5OgJC4JtcjVhTp3fbGBMb1BqJJTd9fOy8ICS5SbMAbq9QV1pIZOg 7tdfq/qDSHpg5lRvARlM1Z8Ov76HAjsrys5/c= MIME-Version: 1.0 Received: by 10.216.154.195 with SMTP id h45mr1414079wek.106.1266416676156; Wed, 17 Feb 2010 06:24:36 -0800 (PST) In-Reply-To: <4B7BFAF3.5090206@phpbb-seo.com> References: <4B7BEC58.3020909@phpbb-seo.com> <4B7BFAF3.5090206@phpbb-seo.com> Date: Wed, 17 Feb 2010 09:24:36 -0500 Message-ID: Subject: Re: Junior developers From: Andy Levy To: dcz Cc: users@subversion.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Feb 17, 2010 at 09:19, dcz wrote: > Thanks for responding. > > I was hopping that someone did put something together to handle this. > It looks like doable with a pre-commit hook that would have a look in a d= b > (or a file) to find out if the user is JD or SD. For JDs, the commit coul= d > be made dry-run, and the script could in such case send a mail to SDs who > could later reply to in order to do the actual commit (eg authorize it), = or > not. Hook scripts do not work in this way. They are non-interactive and especially in the case of the pre-commit, will block others from committing while the hook is executing. There is no "dry run" for a commit. It's conceivable that you could check the user ID in the pre-commit, and if the committer is JD, reject the commit while mailing a diff to SD which represents the change being attempted. This would require a lot of overhead on the server though. Honestly, I think you're trying to apply an excessively technical solution to a fundamentally non-technical idea. > Unfortunately, I still have a lot of doc to read about svn and not so muc= h > time as us all. > But since I saw it working, I keep faith ;-) > > > > Le 17/02/2010 14:30, Andy Levy a =E9crit : >> >> On Wed, Feb 17, 2010 at 08:17, dcz =A0wrote: >> >>> Hello, >>> Here is what I'm trying to do : some user (let's call them junior >>> developer) >>> should require their commit to be authorized by other (senior developer= ) >>> before they would actually be committed. >>> >>> Since I saw this feature on an svn (though I do not administrate this >>> one, >>> so I can't tell how it is done, but it's svn for sure) and found it >>> pretty >>> useful, I was a bit surprised not to be able to find any topic about it >>> after hours a googling. >>> >>> Would be very nice if someone could share thoughts about how to set suc= h >>> feature up. >>> >> Subversion has no such feature, which is why you can't find anything abo= ut >> it. >> >> You can approach this a couple of ways. 2 that come to mind immediately: >> 1) Junior developer (JD) submits patches to the senior developer (SD). >> SD reviews the patch& =A0commits when he's satisfied. >> 2) JD gets his own private branch& =A0can commit to it all day long. >> When he's ready for a code review, SD looks it over& =A0merges JD's work >> into trunk (or wherever your main development is done). This will >> require that JD's branch be kept up to date with regular merges from >> trunk so that he's not conflicting with other peoples' work. >> >> >> > >