Slashdot Mirror

Based on this page Linux F*** Count this must be a bid by Microsoft to F*** KILL LINUX!

Maybe they've measured in a specific way?

I'm not going to say whether Linux or Solaris is a better OS. But it seems like the Linux code might be a bit more entertaining to read.

I don't think you could get a reward but a f*ck count.

The patent was filed on 3 Feb 1999. Depending on how you read the legalese of the claims, use of CVS (for web development) may or may not be covered by this patent.

Prior art with regard to CVS is easy to prove. Back in 1997 cyclic.com already had a CVS and the Web page. That page references amongst others L.D.Stein's book How to set up and maintain a web site, that makes mention of the use of CVS for version control.

By 1998 the same page on cyclic included a link to Sean Dreilinger's CVS Version Control for Web Site Projects (link to current version). archive.org does not appear to have the original document, but the link is on cyclic.com circa Dec 1998, and Sean's Copyright is dated back to 1997.

Cyclic.com also had a page listing sites using CVS (for web development, 1998).

And just in case anyone didn't get the message, WebDAV (RFC) has a history (and more) going back to 1996. The RFC was published in (surprise surprise) Feb 1999.

I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).

Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML). If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.

In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:

1. Use a UNIX server, for both repository and pserver (client/server, runs on port 2401 by default, setup in /etc/inetd.conf) daemon (recommend both be on the same system, although there are exceptions to this rule). The UNIX CVS server is just so much more flexible, although our SV office uses CVS on NT (but they are NT-only on the client side). Since most Linux distros come with the latest CVS software, stick with Linux for your server (the CVS server/repository should always have the same or later version than any client).
2. If performance is important, make sure your server has a lot of memory if you run pserver (again, client/server daemon on server's port 2401). When you do, the server needs 1.2-1.5x the memory of the largest file checked in, otherwise, thrasing will occur as you swap pages to/from memory. Again, I _highly_recommend_ you run pserver for access from NT clients.
3. On the UNIX side of things, you don't have to use pserver. You can directly access the repository via NFS mounts. This is slower, but, for large files, you do not run into the thrasing issue on the server. In a nutshell, pserver puts all the burden (incl. memory usage) of the diff/commit on the server, whereas clients that access the repository directly do all the work. Even though you run pserver (for your NT clients), you can still access the repository directly on UNIX clients.
4. Do *NOT* checkout via NT to the same directory as via UNIX. E.g., if /home = \\server\home, do not try to checkout to /home via UNIX and then commit via NT from \\server\home, or vice-versa. The reason for this is that while the repository is OS-independent, the checked out working directories have OS-specific details (e.g., drive letters when checked out via NT, which the UNIX cvs client won't understand -- plus LF/CR issues where NT gets the later automatically added). Either adopt one of two philosophies (or both, depending on your user):
   • If you need to have working files accessable in the same place from both NT and UNIX (e.g., /home and \\server\home), then do all your cvs actions from the _UNIX_ side. The only issue you'll run into is any LF/CR that a Windows application would expect (since only LF will be used for line breaks since the working directory created/modified by UNIX). Since most of my Windows development tools don't mind LF-only breaks, I didn't have any problems with this.
   • The other philosophy involves a strict separation of working directories from NT and UNIX. Note, both clients still access the same, central repository and the same info. But when working, check out files via NT to a NT-only area and files via UNIX to a UNIX (possibly NT-also) area. This is what we also do with some people: Check out via NT to their local hard drive (which cuts down on network usage when they work), committing at the end of the day (for backup purposes), with other files being checked out to UNIX on the file server (and then accessable via both UNIX and, limited, NT over NFS/SMB shares -- which doesn't need to be committed at the end of the day since it gets backed up on the file server itself).
   • The use of each will depend on your workflow, possibly a per-user thing.
5. Be cautious about what you modify the CVS respository directly, but don't be shy to do it occassionally when you absolutely need to. This is what I love about CVS over other VC systems, a very understandable repository setup. Don't do it unless you cannot get a cvs client command to do what you want, don't do it reguarly and manually log anything you do to the repository for future reference. After a year and a half at my job, I have probably gone into the repository about 2-3 dozen times and haven't had any issues yet. Again, I haven't had such good luck with commercial systems and direct repository modification (when required).
6. Even if you are using a UNIX-only checkout environment, you can always use the nice, visual WinCVS client on the Windows side (provided you have a Samba share) to look at working file status (e.g., modified, current, etc...), but don't use to checkin/out UNIX working directories. If you are checking out via NT, then WinCVS will be a natural client choice. Just configure it for pserver, port 2401 and you'll be cooking.
   [ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
7. Don't forget to set some basic variables in all your user scripts (or in a global script called at login), e.g.:
   • CVSUMASK 007 -- just like a regular umask, only for cvs checkouts
   • CVSREAD 1 -- set if you want to force users to do a "cvs edit" before editing a file (great for keeping track of concurrent edits/development), unset (or don't set) if you don't.
   • CVS_SERVER server and CVS_PASSFILE $HOME/private/.cvspass -- if you use pserver (client/server) access (or unset/don't set if you don't).
   • CVSROOT /home/cmroot/cvsroot or CVSROOT :pserver:$USER@server:/home/cmroot/cvsroot -- the former for direct repository access by client, the later to use pserver.
8. Also get some basic aliases down for your UNIX clients, e.g.:
   • alias cvs '/usr/local/bin/cvs -d /home/cmroot/cvsroot' -- accesses CVS repository /home/cdroot/cvsroot directory
   • alias cvs '/usr/local/bin/cvs -d :pserver:$USER@server:/home/cmroot/cvsroot' -- accesses CVS respository on SERVER at /home/cmroot/cvsroot via pserver (client/server)
   • alias noncvs "cvs -n -q update -I '! CVS' -r HEAD" -- List all non-current or unknown files in working directory from repository (I use this all the time)
   • alias noncvsi "cvs -n -q update -r HEAD -- same as previous, except apply ignored file list (which are listed in file $CVSROOT/CVSROOT/cvsignore -- which you'll want to checkout and modify for your site).
9. Do *NOT* make your server public. CVS is NOT a secure server, unless you use something like Kerberos client/server (instead of pserver, on a different port, I've never done this), or pserver with SSH as the remove shell. If you are going to run a publicly accessable CVS server, you'll want to run in at least pserver mode using SSH or, in the worst case, pserver with different usernames/passwords directly in the CVS admin files (rather than using the default of the local UNIX accounts). I highly recommend _against_ running a server that is both internally and externally accessable. If you need to, setup two separate servers, with two separate CVS repositories and run a cronjob to update the external server on a regular basis. Better yet, get familiar with "cvs export" on automating the export of files from the CVS repository (withOUT working CVS info) to archives, external servers, etc...
10. Lastly, if you have not adopted Cygnus' Cygwin GNU environment as standard on your NT desktops, do it now. No need to pay others for UNIX tools on NT, Cygwin is all you need. Do it even if you don't use GCC, and do all your development via Visual Studio, etc... There are just too many good UNIX CLI tools to ignore in there and you'll wish you'd had them. A CVS client is included (or you can use WinCVS').

[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC). VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1, :2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]

-- Bryan "TheBS" Smith

CVS Version Control for Web Site Projects is always what I reference for help. In addition to that documentation, they also host the standard Cederdqvist CVS Manual in HTML, which I reference continuously for software development.

I'd simply remote into the web server and use the simple cvs export -r tag -d dir module command to export the files without CVS admin files (provided I cvs logged in to my remote CVS server via SSH/pserver, unless local). Or if you keep the CVS info in the directory for easy updating, simply cvs update -r tag in the directory you want to update.

-- Bryan "TheBS" Smith

CVS Version Control for Web Site Projects is always what I reference for help. In addition to that documentation, they also host the standard Cederdqvist CVS Manual in HTML, which I reference continuously for software development.

I'd simply remote into the web server and use the simple cvs export -r tag -d dir module command to export the files without CVS admin files (provided I cvs logged in to my remote CVS server via SSH/pserver, unless local). Or if you keep the CVS info in the directory for easy updating, simply cvs update -r tag in the directory you want to update.

-- Bryan "TheBS" Smith

I agree with RG Ristroph's post -- the hard part is establishing version control -- the tool is not the most important part. That said, CVS is a pretty good tool. It works well over both LANs and WANs (unlike sourcesafe, for example), handles branching/merging about as well any as tool can, and bonus, is free. You *will* need someone who is dedicated to managing the system and answering questions. It may not (should not) be a full-time job, but until people are up-to-speed, they will make mistakes, and you need someone whose priority it is to fix those mistakes, and help the other developers learn how to accomplish what they need. (The above is true of any version control system, by the way, not just CVS.)

Before you install any VC system, you need to decide what you're trying to accomplish, and design the procedures to do that. CVS (or whatever) is a tool, not a methodology.

Finally, here are some hopefully useful links:

• Karl Fogel's CVS book (actually, portions of it, mostly dealing with using CVS), which I find more readable than the Cederquist manual.
• Some links about using CVS for websites:here, here, and here. Different view points, worth reading, and generally applicable even if you choose something besides CVS.

I just went through all the hoops this week installing CVS to manage my intranet that uses PHP and perl to run backend databases.I also use it to manage other binary files, text config files, etc. CVS isn't just for source code anymore! I did have some hurdles, but this particular site really helped me out: http://durak.org:81/cvswebsites/ . Troubleshooting is alittle on the darkside, but in Sean Dreilinger's CVS Version Control for Web Site Projects , there's simple directions for installing CVS on Linux. He recommends trying the cvs login command, but I found telnet 2401 better. If your inetd.conf file is incorrect, you'll get a list of the valid CVS commands sent back to you. I found Sean's configuration to be correct for Linux, but found some of the docs on Cyclic's site to have errors in these files. If your telnet 2401 goes correctly, just enter anything and you should be returned with a bad auth protocol start: Other than that, CVS is really straight forward. I only use the command line interface, as that has everything I need just fine. There's other interfaces, namely jCVS, but I haven't tried it yet.

At the bottom of ESRs page is a link to this image which displays a graph of the linux kernel with files/1000, lines/10,000, words/100,000 and source tree size (MB).

My personal theory on this problem is that people tend to work on things that don't work for them. For me, I've never had a need to work on fetchmail, as it's always dealt with my environment and desired setup flawlessly.

I'd love to come up with a more detailed analysis of this stuff, as you mentioned though. Perhaps somebody taking some sort of sociology class could find an excuse to write this paper?

web-dav (web distributed authoring and versioning) is a good first place to check, i think with the appropriate apache module it supports in-place page locking and editing via msie 5. if your user community is semi literate, you might also look into cvs to manage web development, which is easier and more effective imho. HTH