Version Control (was: DBs and Events)

s001gmu at nova.wright.edu s001gmu at nova.wright.edu
Wed Feb 18 10:04:52 CET 1998


On Wed, 18 Feb 1998 coder at ibm.net wrote:

> 
> On 16/02/98 at 03:37 PM, Vadim Tkachenko <vadimt at 4cs.com> said:
> >

[...]

> >Right now I'm trying to choose the
> >right one for UNIX project[s], so far figured out how to use RCS, looking
> >for information on CVS, know about anything else?
> 
> RCS, CVS, SCCS and company are version control systems.  They have nothing
> to do with filesystems per se -- they operate at the file or directory
> level.  I use RCS -- I haven't looked into CVS (tho I suppose I should). 
> Comparitively RCS is a superset of SCCS, and is quite simple.

Having gone from SCCS to CVS at work recently, I feel I can comment a bit.
As I recall, SCCS has you check out a file, and while someone has it
checked out, noone else can commit changes to it.  They can certainly
work on it, but they can't commit changes.  CVS gives everyone a complete
copy of all the source code, as of the last checkin (you can set up tags
as well, to get the last 'fully working' copy or somesuch). 

> Note a versioning filesystem would essentially do RCS int he background
> without your ever having to touch it.  cf ClearCase.
> 
> >RCS is good enough, the only thing I haven't figured out yet is how to
> >allow multiple users to edit and compile the code with a minimum overhead
> >- the kind of people I'm dealing with is having difficulties setting
> >CLASSPATH...

Editing and compiling your own changes are pretty easy with CVS... you get
a complete copy of the working directory for the project in question.
When you are done making changes, you then have to merge those changes
back into the main line of code, or create a branch.  Usualy, with
multiple people working on one project, with one goal, you merge.
Branching is only good if you have seperate goals.  CVS's merge util is
pretty decent (as I said above).  You only run into problems if you have
two people changing the same method/function in the same file in radically
different ways, or if two people make some pretty radical changes to the
same files.  If your project is really large, you may want to break it 
into a few logical sub-projects and store them seperately in CVS, so each
person doesn't need to grab huge chunks of code they won't be hacking on.

-Greg




More information about the mud-dev-archive mailing list