[UPHPU] Source Control Questions

[Bryan Petty]

On 12/29/06, Lamont Peterson <peregrine at openbrainstem.net> wrote:
> One of the things that Bazaar (baz) & Bazaar-ng (bzr) do for you that CVS
> (cvs) and Subversion (svn) can not, is that each person can commit whenever
> they need to.  With cvs or svn, there is one repository that everyone shares.
> They have to access to that one repository in order to run (almost) any cvs
> or svn commands (and definitely to commit anything) at all times.  If that
> one copy of the repository becomes corrupted in some way, that's it; you'd
> better have good, ultra-recent backups.

You forget that both CVS and SVN have a long history of managing
thousands of repositories that have never seen corruption. You also
forget that having one single repository to make your changes against
and pull updates from is a good thing for projects that aren't open
source, GPL, and work like the Cathedral, not the Bazaar. To top this
all off, everyone knows that the main repository isn't something that
goes without having an automated backup system in place no matter what
system you're using; Bazaar is just as prone to corruption.

> With baz or bzr, each person has their own repository (called an archive in
> the parlance of their documentation).  You keep a "mirror" copy on a central
> server, but I can work completely disconnected from the network (like on a
> plane or at home w/o VPN).  You simple mirror your repos to the central
> server when you can/are ready to.  Then, others can merge from your branch.
> Also, there is so server-side code to run; you just need ssh access to be
> able to write and read files from some central storage (i.e. file server).

Nothing in Dan's list implied any use of a distributed VCS. In his
situation, doing so could lead to developers forgetting to pull code
up to the appropriate repositories, or not bothering to do so because
of some confusion with the review system. It also means that there
could be conflicting code other developers are working on that the
code reviewer (the person doing the repository merges) would run into
instead of the original developer meaning there's a much higher chance
of introducing bugs into production code.

You're trying to substitute the traditional method of development with
some unstable form of code management using distributed repositories.
What's wrong with the time-tested methods of everyone committing their
changes, reviewers looking through logs, putting the project in
feature-freeze, then code-freeze, doing testing, fixing bugs, then
tagging/branching stable? It's generally a known fact that grabbing
code from CVS/SVN head is testing code, not production.

> I've used all 4.  I've used cvs going back 10 years, svn going back about 2,
> baz for 2 and bzr for 1 (it's very new).  I will never put new code into cvs
> or svn again, even if it's a just-me-by-myself project.  Yes, people are very
> familiar with cvs & svn and there are several front-ends already available.
> The paradigm of baz & bzr requires a shift in thinking.  People don't like to
> leave their comfort zones, especially with tools like cvs that required lots
> of effort to learn how to work around all the problems.  cvs & svn are just
> too limiting.

They aren't limiting at all, especially considering they both can do
everything Dan is asking for and more. In my view, bzr is more
limiting due to lack of good GUI front-ends. I know of one developer
that really doesn't like it:
http://www.kdedevelopers.org/node/2024

> > > * I'd like the ability to review code before it gets committed, to
> > > prevent obvious stupidities from getting into production code
> >
> > Good plan. I am not aware of any automated services to facilitate
> > this, but I find peer review to generally be sufficient for
> > preventing obvious mistakes.
>
> I've already commented on this elsewhere in this thread, but, since I spoke
> about cvs, svn, baz & bzr here ...
>
> This is harder to do with cvs or svn, but not impossible.  The real problem is
> when you need to reject code.  The "easiest" solution if you are going to use
> these is to manually copy code from separate, per-developer central
> repositories, but that means that all your history is lost, in addition to
> several other problems that make it much harder for a team to work
> coherently.
>
> baz & bzr make this really, really easy.  You simply create a "trunk" (or name
> it whatever you want to) archive that your merge code from per-developer
> archives (actually the mirrors on the central server).

Again, there's nothing stopping this from being done on the testing
branch/trunk of code like so many projects have done in the past
before branching/tagging stable. You don't lose any history. Just
because bzr is the newest, hottest VCS to hit the scene doesn't mean
everyone should switch to using distributed repositories, nor does it
mean that CVS and SVN aren't proven VC systems with thousands of
successful projects. I also highly doubt that bzr has much of a
history with proprietary code repositories to have been proven a
better system than CVS or SVN in those situations either.

> > > * I want to be able to keep some files "hidden" from some developers -
> > > specifically the files that contain our DB password info, credit card
> > > gateway info, etc.  They would need to stay in the live code and/or
> > > the repository, but not get checked out along with everything else
> > > when someone grabs the code.
> >
> > I am fairly certain that you can restrict access to files in the
> > repository.
>
> Not easily.  The main problem with this is that developers (at least those
> that are good enough to have on your staff) will know how to find the code,
> if it's in the same tree.

There's nothing hard about this with SVN, but with any VCS, it would
be best to use the same method most projects do with configuration
files: make a config.ini.dist file where basic changes are made, and
put an ignore on config.ini. Then you only need to worry about whoever
is doing administration of updating config.ini on the production
server, and your passwords are _never_ committed to your VCS.

There's no reason Dan needs to setup multiple servers with separate
repositories, or any of that ridiculous advice you've just given.

> > > * Expanding upon that, it'd be nice if I could just give someone
> > > access to certain parts of the code and not others.
> >
> > This is also easy with a versioning control system. The code can
> > exist in various branches and other chunks that you can specify who
> > has access to.
>
> Again, this could be done pretty easily with baz & bzr, but it's not so easy
> with either cvs or svn.  Basically, I would do the same thing as for
> other "restricted" code (that appears just before this part in this message)
> and then use FACLs (see the setfacl(1) and getfacl(1) commands) to control
> access to the archive directories.
>
> Of course, his would work best if your apps are modular in design.

SVN has ACLs that can be set on specific directories with a repository
for read/write access that are very easy to setup. Don't say "it's not
so easy" unless you really know it isn't. That tactic of yours has led
to a lot of bad advice this round.

Regards,
Bryan Petty