subversion

[kentborg at borg.org (Kent Borg)]

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.