Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!lll-winken.llnl.gov!trib.apple.com!agate!boulder!rintintin.Colorado.EDU!vilhuber From: nelsoni@rintintin.Colorado.EDU (Ian S. Nelson) Newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc,comp.unix.advocacy Subject: Re: Linux vs FreeBSD Date: 5 Dec 95 22:42:26 GMT Organization: University of Colorado at Boulder Lines: 52 Distribution: comp Message-ID: <vilhuber.818203346@rintintin.Colorado.EDU> References: <489kuu$rbo@pelican.cs.ucla.edu> <49smvs$8gd@josie.abo.fi> <49tban$978@times.tfs.com> <4a10kr$k06@mark.ucdavis.edu> NNTP-Posting-Host: rintintin.colorado.edu X-Newsreader: NN version 6.5.0 #8 (NOV) Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:30142 comp.unix.bsd.freebsd.misc:10336 comp.unix.advocacy:12131 obrien@cs.ucdavis.edu (David E. O'Brien) writes: >>Am I correct to think that the FreeBSD "equivalent", this CVS or >>whatever you called it, can't be _read_ except by a small core team? >>Whatever for? Keeping people from making their own changes and writing >>to it I can see, but...? >I believe what we have here is basically a misunderstanding (or total lack >of knowledge of source code revision control systems). I guess it only >makes sense since so many Linux and *BSD users have never programmed in a >commercial environment (especially one working to DoD stds). DoD standards call for CMM Level 3 and up. That is far far beyond version... Any programmer at all should be using RCS or CMVC or something. DoD standards or not, it is just a good idea. >I would highly suggest doing a man on `SCCS', `RCS', or `CVS' on your >favorite Unix box. If you get no hits, try another. Or ftp RCS from >prep.ai.mit.edu:/pub/gnu/rcs* and read the paper written about it. >A code revision system simply tracks the *CHANGES* to the source code. >This allows you to get a copy of that file/system foo looked like last >Tuesday. This could be useful to see how a file changed, or to go back to >an older version of a file because you make changes that were bad. Often >fixing one problems creates another. So it useful to see what has changed >from system X to system Y when something worked in X, but is now broken >in/for Y. These are the reasons for using SCCS/RCS/CVS. >As stated so many times, the *latest* source is always available for *BSD, >just like for Linux. EXCEPT, that for *BSD it is one-stop-shopping. For >Linux I would have to visit WAY too many ftp sites for my tastes. Not just that, but on a few occasions I have grabbed a new kernel to fix a few defects I've been dealing with and the new kernel ends up breaking other things. Version control systems make it much easier to pop back out the files I need from older versions. Moreover, it saves tons of space in most cases: You could probably have then entire RCS tree of Linux for all versions in space that isn't much bigger that 2x the size of the source now. I would think that a lot of people would be interested in that. I've got CD-ROMs with 20 copies of source and a lot of them just have minor changes. >> System'' that will forever prevent it from truly becoming a Big Success >> (i.e. bigger than it is now among innumerable hobbyists), and these two >> things are both tightly interrelated: >> >> 1) The lack of a central authority for the entire OS, and >> >> 2) the lack of any single party who is concerned about (and who >> takes personal/corporate responsibility for) the level of >> standard conformance (both ANSI and POSIX) for the entire OS. Many linux users seem to think that those are pluses.