subversion

[Adam Fletcher]

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