MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Version Control (was: DBs and Events)
On Wed, 18 Feb 1998 coder#ibm,net wrote:
>
> On 16/02/98 at 03:37 PM, Vadim Tkachenko <vadimt#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
- Thread context:
- Re: [MUD-Dev] DBs and Events, (continued)
- Re: [MUD-Dev] DBs and Events,
Jon A. Lambert jlsysinc#ix,netcom.com, Thu 12 Feb 1998, 17:45 GMT
- Re: [MUD-Dev] DBs and Events,
coder coder#ibm,net, Mon 16 Feb 1998, 02:47 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
Vadim Tkachenko vadimt#4cs,com, Mon 16 Feb 1998, 23:30 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
coder coder#ibm,net, Wed 18 Feb 1998, 10:34 GMT
- Version Control (was: DBs and Events),
s001gmu s001gmu#nova,wright.edu, Fri 20 Feb 1998, 09:55 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
Vadim Tkachenko vadimt#4cs,com, Fri 20 Feb 1998, 21:32 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
coder coder#ibm,net, Fri 27 Feb 1998, 06:02 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
coder coder#ibm,net, Sat 28 Feb 1998, 04:57 GMT
- Re: [MUD-Dev] Version Control (was: DBs and Events),
Jon A. Lambert Jon.A.Lambert#ix,netcom.com, Mon 02 Mar 1998, 15:07 GMT
[ Other Periods
| Other mailing lists
| Search
]