subversion

[adler at stephenadler.com (Stephen Adler)]

I'm having issues with mod_auth_pam and httpd.... :(

Adam Fletcher wrote:
> We're a subversion shop here, a conversion from CVS, and it's been
> incredibly successful. It's successful because most of developers hated
> CVS' opaque command line and its archaic treatment of binary files. Also
> it's successful because of all the web tools available for subversion,
> for example using apache as front end allows us to control access
> through mod_pam and other methods, rather then having to use a cvs
> passwd file. 
>
> Our developers haven't had any issues working with branches/tag in
> subversion, but I hear you that it's nice to have some tool-enforced
> structure. 
>
>
> Thanks,
>
> Adam Fletcher
> Director, Information Technology
> PowerSteering Software, Inc. 
>
> -----Original Message-----
> From: discuss-bounces at blu.org [mailto:discuss-bounces at blu.org] On Behalf
> Of Kent Borg
> Sent: Friday, August 18, 2006 10:42 AM
> To: Stephen Adler
> Cc: discuss at blu.org
> Subject: Re: subversion
>
> On Thu, Aug 17, 2006 at 06:41:40PM -0400, Stephen Adler wrote:
>   
>> Believe it or not, I like the fact that there is no tag or branch,
>>     
> just 
>   
>> copy and merges.
>> I think is quite an elegant solution. It does put the responsibility
>>     
> on 
>   
>> the subversion
>> administrator to make sure the trunk and release directories are 
>> protected from users.
>>     
>
> Yes.  But if one is a simple programmer with work to do, Subversion
> might be a really bad choice.  It demands time and wisdom that the
> programmer with a job to do doesn't necessarily have.  A tool that
> requires an experienced administrator is scary to a small shop that
> can't afford that overhead.
>
> Imagine you land in a new organization and are told to set up
> Subversion.  Immediately you are going to reimplement a bunch of the
> stuff you did last time.  For a lot of people it is valuable to have a
> tool that already has that higher lever implementation in place.
>
>   
>> What I'm doing is setting up the following access model to my
>>     
> repository.
>   
>> Only users can checkout a branch, and preferably each user works on
>>     
> his 
>   
>> own branch.
>> when the user is done with their major coding, then the administrator 
>> does the merge
>> into the trunk and then the release administrator makes a release from
>>     
>
>   
>> the trunk.
>>     
>
> Sounds scary to have programmers working in code that might get pretty
> divergent, but it might work.  
>
> I am intrigued by the idea of distributed repositories where an
> individual programmer can track his/er local changes locally, but have
> the master repository be kept pretty flat and clean.  A lot like your
> model, but the forking is more optional and clearly the responsibility
> of each programmer to manage any divergence.
>
> In a previous job every checkin (even by manager types) required a
> code review and signoff from another programmer, all as part of the
> checkin procedure.  They used Bitkeeper, so if a programmer wanted to
> keep track of local changes that was easy, but the main code was
> rather flat and mostly unforked.  The downsides were (a) is was based
> on ornery Bitkeeper, and (b) the system had to be built locally, it
> wasn't already available as a well crafted tool.
>
>
> -kb, the Kent who isn't opposed to general purpose, elegant tools, but
> the Kent sometimes has a job to do and would prefer a pre-built tool
> that comes already well crafted and already as baroque as necessary to
> get the job done.
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://olduvai.blu.org/mailman/listinfo/discuss
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://olduvai.blu.org/mailman/listinfo/discuss
>
>
>