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

[Erik <br0ke@math.smsu.edu>]

On 24-Oct-99 Shadow Mint wrote:
> Yeah oops! I ment CVS. =)
> 
> Thanks all! I'm still a little confused though, maybe you can help me out...
> 
> 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...
> 

the patches get merged into a single tree. Patch is capable of handling a
degree of varience in the target file it's updating. CVS also has the ability
to look at older revisions... If I'm working on a chunk of a file, and
billyjoebob is working on a chunk of that file, and they're different chunks,
then I can update the main repository, bjb can update the main repository, and
both of our modifications are happily merged into that tree. If we're working
on the SAME chunk of the same file, then whoever gets their second will
probably get a hunk failed error and their patch won't be applied to the main
repository, in which case they tar up their tree (for safe keeping), update,
and see what they gotta do to fit their thing (I think). This rarely happens,
as people engaged in cvs work are active on the mailing list for their project
and (usually) declare intention :)

> 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...
> 

If you modify your local tree, then do a cvs update, your modifications persist
in your local tree. That means you can stay current with the tree and still
work on your modifications. When you upload, it uploads what you changed, so
you're not over-writing their updates and downgrading them. Ettiquite has
evolved where patches are expected to be small and quickly merged, so prevent a
wide varience between the master tree and your modified tree, so cvs doesn't
oops it. Often there is a small core group of people entrusted with write
access, and people who don't have write access submit patches (like unified
diffs) to these people for review and application to the master tree. CVS
doesn't understand write access per module, it just knows global write access,
so another ettiquite rule shows up where you only write to the module you tend,
and if you want to modify someone elses, you email a patch to one of the
tenders of that module.  

> 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.
> 

the whole point of a cvs server is to download and apply patches more easily :)
Patches are good for frequent small updates, tarballs are good for big massive
updates. Since most distributed development depends on having common access to
a development base, that means they must update frequently, and changes will be
small. So patches are the best way to apply updates for distributed
development. If you develope in a small group in the same room, then cvs
doesn't really offer too much (it's still useful, but it's not as important to
a closed local group as it is an open distributed group).  

> Later!
> Shadow Mint.
> 

        -Erik <br0ke@math.smsu.edu> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.