Re: Open source game design: What IS an RCS server?

[Steve Baker <sjbaker1@airmail.net>]

Shadow Mint wrote:

> CVS lets you upload with patches, and so on for the various different modules of
> the source. This much I can understand, sounds like a pretty cool way to go.
> However, if two different people are working on the same  code, you'll get a
> whole bunch of different branches of the same program in the end! Where people
> have worked on code from X and others on code from Y and in the end it's just
> one huge mess, and everyone has to sit tight while they try to resolve what the
> hell to do...

Not every change results in a new branch.  Generally, each new change is
simply added into the current branch in a linear chain.

When two people have been off patching the same file, the first person to
check in the change simply replaces the current file - the second person
has to merge in their changes.  If the changes don't overlap, CVS lets
you do this automatically (although that's rather dangerous) - if they
do then you have to resolve the changes manually.

Most projects don't create a lot of branches - often just two - the
development branch - and the 'stable release' branch. The latter gets
small bug fixes and such, the former gets everything.  Those two branches
could in theory get totally out of sync - but they don't in practice.

Eventually, when the development branch is stable enough, it becomes the
new stable release and the old stable branch is no longer added to.

Remember that one of the joys of CVS is that it maintains a historical
record of changes - and you can generally "back out" changes that you
subsequently realise were a bad thing.
 
> What stops this? I can understand that as modules, each area will be distinct
> and independent (to a degree), so working with in those boundaries I can accept,
> but if an idervidual comes and chooses to make a patch to do something, surly it
> must be a real pain for everyone else, who has, in the mean time, changed the
> original code...

Well, again, that's more of a theoretical problem than a practical one.

If someone is planning a major change to a module, and he doesn't tell
everyone in advance, then he may well find that a gazillion small changes
have been made in the meantime - and be faced with a hard 'merge' when he
submits his master-work.  However, that's why we have mailing lists and
why we have to communicate a lot.

Some wasted effort is inevitable with web-based development.

> Thoughts? It seems to me you still need to set up workgroups to work on each
> module, and the only bonus of having the CVS server is that you can download
> patches more easily.

For large projects, it generally turns out that various people will become
the de-facto "owners" of certain parts of the project.  Since it's generally
unwise to give totally open write access to the CVS server, the overall
project lead will generally have just a few trusted people who can write
to CVS and commit changes.  Those people act as "gatekeepers" - and hopefully
they take the time to examine the changes they are committing...especially
if they don't know the individual who is offering the patch.

Without this kind of human control, it would only be a matter of time until
some jerk would submit a patch containing a virus or something. (I'm rather
suprised this hasn't already happened actually).

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)