Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

CVS Pocket Reference 112

Posted by timothy from the tasty-dried-roasted-and-salted dept.
On-the-fly organization may suffice for keeping track of scripts /bin on your local machine, but larger projects have more at stake when it comes to coordinating the effort of programmers, especially when they're not even in the same timezone, never mind in the same room. CVS has become the lifeblood of many such projects. Reader Craig Pfeifer suggests CVS Pocket Reference as a good way to help keep that lifeblood flowing.

CVS Pocket Reference
author Gregor N. Purdy
pages 75
publisher O'Reilly & Associates
rating 8
reviewer Craig Pfeifer
ISBN 0596000030
summary Indispensable handbook for administrators of all but small CVS installations, and probably for the small ones as well.

*

The Scenario

As a former CVS repository administrator, I wish I had this book when I started, it's much easier than pawing through the canonical documentation for quick answers. CVS is the #1 choice for open source projects. If you plan on organizing or working on an Open Source project, this is reference might be for you.

What's Good?

This pocket reference is a guide to basic CVS functions (branch, merge, update) but the real strength is in the description of server and client side control files and environment variables. Gregor describes how to setup email notification when someone commits a change to the repository, how to customize the repository to treat certain files as binary (versus text), and other useful things. He even goes as far as to describe how to hack the repository to change it's structure while the project is in motion, and how to hack the sandbox (the name for a developer's work space) to change any property such as which branch or repository the files will be committed to. Of course you don't really need this because developers never make mistakes, it's always CVS' fault &ltwink wink&gt. All in all, it's a great reference for all the bits and pieces of CVS that you're supposed to mess with (and a few your aren't) and anyone who is expected to administer a moderately complex installation should own it.

Gregor also gives pointers to some great add-on modules for CVS: CVSWeb for making your source tree web-browsable, and WinCVS to make CVS look SourceSafe-esque.

What's Bad?

The organization of this pocket reference could use a little help. I've seen reviews for other O'Reilly pocket references ask for an index, but that wouldn't be helpful here. It would be helpful if they added section tabs in the outside margins of the pages (a la their java nutshell series), so that you could quickly thumb to the section you're looking for. Also, organizing the content by server side and client side instead of simply adminstrator and user would help folks to find the specific information they are looking for.

My last gripe is a small, petty one. The books binding doesn't allow it lay flat when you set it down. Yes it's petty, but I hate losing my page when working. You need to keep a medium sized object with a decent bit of heft (e.g. a stapler) within arms' reach to hold it open.

So What's In It For Me?

This reference will not make you a CVS guru, but it will help you remember the command line options (if I had a nickel for every time I typed 'cvs --help tag' I would be frequently mistaken for a Kennedy), figure out what all those little files are without breaking your CVS installation, and most importantly keep you from having to consult the the cannonical documentation for simple things.

If you have inheirited a CVS installation or plan to set one up for the first time, spend the US$9.95/CN$14.95, do it right the first time and save yourself some time and reap all the bennies that CVS offers.

Table of Contents

  1. Introduction
  2. Installing CVS
  3. Administrator Reference
  4. User Reference
  5. Relata

You can purchase this book at ThinkGeek.
This discussion has been archived. No new comments can be posted.

CVS in a Nutshell More

CVS in a Nutshell

Comments Filter:

  • Re:cvs for backup (Score:4)

    by Pilchie ( 869 ) on Tuesday March 27, 2001 @06:28AM (#337519) Homepage
    Actually, CVS clients send the entire file contents when committing. It is only updates that send a diff. This is because the CVS metadata doesn't store what your copy looked like before you changed it. Wait for Subversion [tigris.org](M2 expected RSN (1 April 2001)), for a system that will send diffs both directions, as well as a whole lot more.
    >~~~~~~~~~~~~~~~~
  • It looks like nobody else has done this yet: CVS is wonderful, but has many quirks and limitations that the developers won't fix. Fortunately, there is a project for a next-generation CVS-like system called SVN (a.k.a. "Subversion") here [tigris.org]. That has to be worth a +3 Informative, at least.
  • I'll second this. Perforce is excellent, with good command-line interface, emacs integration, atomic submits, nice handling of different code branches and it work ok over a modem.

    I like it better than CVS. OTOH, Perforce is not free (~$600/seat).

    PVCS is terrible. Really, absolutely awful.

  • Ah ha,

    I jumped ship from delphi after version 3 so was not aware that you could now save dfm's as text by default.

    How well does cvs merging actually work on form files like this. I can imagine it could get confusing.

    Anyway if anything this just increases the advantages of cvs or bitkeeper over source control software that requires locking.

    Dave

  • Re:Use Visual SourceSafe (Score:3)

    by Dave W ( 1310 ) on Tuesday March 27, 2001 @06:48AM (#337523) Homepage
    John,

    I have used PCVS, Source Integrity and CVS. My feeling is

    1. Forget PVCS depending on your need both CVS and Source Integrity are better.

    2. If you use a language like Delphi where you need to lock files when you edit them (because they are binary and simultaneous changes cannot be merged) then Source Integrity is excellent.

    3. For distributed development of systems where all the code is in text files (java, C, C++, python, perl, php etc etc etc) then cvs is excellent due to the way it can merge changes to the same file by different people.

    If you want to look at an outsider that could be the very best look at bitkeeper.

    Dave
  • At the best, it is a very poor excuse for a communication protocol between developers. Usually, however, all it does is to prevent works for being done, and make developers hate each other.

    It is like B&D languages or flowcharts, if your development procedures really are so poor that you need them, they will be insufficient to compensate. On the other hand, if your development procedures are any good, they will only get in the way of doing actual work.

    However, these ideas appeal to narrow minded project managers with no clue of how efficient teamwork works, so they nonetheless get used in a lot of projects, most of which fails.

  • Clearcase is a mixed bag. I've been using it for a few years now and while I *love* what it does, it has lots of drawbacks. To begin with, it's slow as fuck. If you have any sort of sizable development team/source tree you have to throw gargantuan amounts of hardware at it to get it to run well. It's not always completely stable either, especially if you're using it on NT. The tools in Clearcase 3 on UNIX really suck in comparison to the ones on NT (I've heard this has changed in Clearcase 4 but maybe not). And of course then you've got lots of other odd problems - it's expensive, Rational support sucks horribly and Clearcase isn't exactly "cross platform." In short - I think Clearcase is a great idea with some great capabilities and a various powerful model, I just think that it could be done better.
  • atomic checkins on multiple files: basically meaning that you can't really tell what files came in with each checkin, so backing out of a change is a chore, also it's possible to checkin only a part of what wanted to (if the network goes down) resulting in a broken tree

    Do you mean lack of atomic checkins? That would make more sense. It isn't hard to tell what files came from what checkin. The checkin message will match (as long as you make a real one, not "changed some stuff"). You can also use the checkin date, but that can get false hits if another checkin went on at (almost) the same time.

    This would be a pretty big pain to fix since the CVS runs on top of a plain filesystem, so it gets no transactions. If it ran on top of some DB it would be easy, but that would make other problems. I had thought about trying to integrate it into the sleepycat DB code, but never got very far (the sleepycat license isn't great for open source code, even if you can grab their source, so...)

    file renaming breaks file history

    Yeah, that sucks. You can log into the server and mv the file so the comments remain, but then old checkouts get the new name. You can cp the old file, and then it works a bit better, old checkouts get both files. I'm kind of surprised nobody fixed this, but I guess I can't complain much since I haven't gone and done it :-)

    no disconnected operations on the repository(e.g. checking the file history when you are on a laptop in a plane)

    Hmmm, I never really had a complaint about that. I guess I just bought into the CVS kool-aid on that one. Other then bitmover, what revision systems let you do this? How much extra space do they demand (not much of an issue on modern laptops, but still...)

    branching and multiple merges back into the trunk is a little awkward

    I haven't found it so. How do other systems make it simpler/cleaner/better?

    setting up a staging area for integration of changes is similarly awkward

    Again, I never felt so. How is it better on other systems?

    The alternatives

    Not all of those are available on more fringe platforms (the BSDs, Linux seems to have made it big time). I agree Bitkeeper looks really really nice. A shame Linus didn't decide to use it.

    I did an 15 day eval of Perforce, I didn't see any clear advantages over CVS.

    ClearCase ended up getting bought by another group, and they had lots of problems with the setup and other admin issues. CVS of corse can get admin issues, by being so open by default people can screw things up if they don't pay attention. It is a better default if you have good people though.

    Never tried SourceSafe. I gave PCVS a shot, but it munched my source tree in the first few days, and I discarded it.

  • No atomic operations? That does not agree with my experience: if I do a "cvs commit" on a directory, all the files go in at once or they don't go in at all.

    It isn't atomic. If there is a network or other issue 5 files into the checkin those files stay committed, they don't get rolled back.

    It is pretty damn rare that it happens on LANs, but you can force it to check if you want. Reboot your machine part way in. Or just kill off your CVS client. It might be a bigger deal over a WAN, but with my modestly sized project on sourceforge, I haven't had trouble.

    It would be nice if it really was atomic, but it isn't a huge deal to me (mostly because it almost almost almost never causes trouble for me).

  • With a system with atomic checkins, I look in foo.h's log for the relevant global change number, and then I ask what effect that change number had on foo.c. No manual searching.

    That isn't because of a lack of atomic commits, that is a lack of a single global change number. Adding atomic commits to CVS wouldn't automatically buy you a global change number, nor would adding global change numbers need atomic updates.

    You can also fake global change numbers. Make a small script that looks at the CVS tags for GCN_N, tag the current version as GCN_N+1. Run that after every commit (or make cvs commit do it for you, I think you can add a hook). As long as there isn't a network issue, or a crash or something that'l work for you.

    Personally I just go with the commit message, but whatever works for you...

    It's harder when there's not something simple like "superfoo()" to grep for.

    Yeah, 'cvs anno' works great for anything you can grep for. It works OK while looking for additions, but it won't help you find when you removed code. Good commit messages are a must :-)

  • RCS, which CVS uses internally still (the ,v files are RCS files).

  • but the last time I actually was able to use it in a job that I was paid for was 1993.

    Why is that? At my full-time job, we use CVS. For my side consulting gigs, I use CVS. For me 'free' development, I use CVS. IMHO, the best features of CVS is the client server stuff.
    --
    "In the land of the brave and the free, we defend our freedom with the GNU GPL."

  • Visual SourceSafe is much more reliable and easier to use than CVS

    Yeah, for users maybe. Try quickly extracting the source tree for V1.1.8 of your project when you're working on V2.5.1. Even if you've got it labelled properly, it's still a major headache. And don't think that CVS is the only product with gnomes; check out this error message from VSS:
    There is a diff chain size mismatch in file 'DocumentPaginator.java' (hfncaaaa) at version 10 (versions earlier than that version can no longer be retrieved from the database).

    VSS is OK if you're working with MS development tools, but if you're working with anything else, I'd go with CVS.
  • On-the-fly organization may suffice for keeping track of scripts /bin on your local machine

    Or the Linux kernel source!

    Sorry. Mod me down for flamebait, but I couldn't help it.

    -"Zow"

  • no disconnected operations on the repository(e.g. checking the file history when you are on a laptop in a plane)
    If this is a frequent problem for you, you might want to consider doing what FreeBSD committers generally do: mirroring the repository on your laptop (or development box, whatever). John Polstra wrote CVSup [polstra.com] to do this efficiently over the network.
  • I've heard nothing but bad things about Visual Source Safe, such as it loosing changes etc. while I've had no such problems with CVS. OTOH, if you have the big bucks just go with the ultimate system and get ClearCase from Rational.
  • Someone moderated me troll? That is damn funny. Now I understand how George Bush became President.
  • I'm not quite sure why hardly anybody I work for uses CVS. Here where I work, bunches of people use Linux for their work. We have clients that we port from VAX, AIX, SUNOS, etc. to Linux. Just yesterday I finished mods to the linuxthreads code to allow stacks on the initial thread to be larger than 2 megs. We did that because we're porting some FORTRAN code from VAX to Linux, using some compatibility libraries that our company originally wrote for other UNIX systems. Fortran declares space on the stack mostly, so 2 megs wasn't enough.

    So, it's not like we're not into hard core Linux hacking here, but by the time I get onto projects (my job is mainly doing the really hard stuff that nobody else can figure out) the version control system has already been picked out, and it's usually rcs or pvcs.

    At home, I use CVS. One thing I forgot to mention is that CVS is great for use as a "briefcase" system. I can make changes in source on multiple computers, like my laptop and my desktop machine, and when I need to integrate the two, I just commit it into the archive and update the other copy. Plus, I keep my source always checked out on one machine, while the archive resides on another machine. If one machine fails, I still have relatively up to date copies on the other machine. EZ redundancy.

  • I love CVS (Score:3)

    by PD ( 9577 ) <slashdotlinux@pdrap.org> on Tuesday March 27, 2001 @06:36AM (#337537) Homepage Journal
    but the last time I actually was able to use it in a job that I was paid for was 1993.

    I've used pvcs lots, and rcs too. Can I tell you how much it sucks when some fool on the team comes in at 6:30 AM and locks the one single header that everyone needs, and doesn't check it in until he goes home at 4PM?

    a) CVS is great for that situation. It would also help to lay out header files in a smart way. Alas, I hardly ever get to start a project, but I sure as hell finish them.

    b) pvcs sucks because of the rule that the suckiest and most selfish programmer on the team also happens to be a bright and cheery early riser, just so he can check out that important file before I get my hands on it.

    c) I haven't mentioned clearcase. The less said about that horrendous mess the better.

  • I've been using this [thinkgeek.com] CVS book for a reference/tutorial. I find it's a good mix of both, and has gotten me to the point where I don't need to look at it much anymore.
  • No, you're not the only one confused. I'm also confused by the fact that the article says "reader Gregory Purdy", when the review appears to have been written by Craig Pfeifer. The ISBN for the book reviewed is the same as the O'Reilly Pocket Reference that I have on my desk right now, too. And, what's up with the sheep looking over each other, anyway?
    BTW, the O'Reilly is an OK book, but really not the only reference you'll ever need as a startging-out CVS admin. I think that the "8" rating is about accurate.
  • I don't agree that CVS sucks, but this review certainly does.

    How does it suck? All in all I'd say his review is a hell of a lot more useful than your empty diatribe.
  • I had to use PVCS some times ago.

    Urg, quite often I had to bypass the User Interface to manipulate directly its files!

    As the PVCS we were using was under Windows, all our files under Unix were on the format 8.3..

    And it was only a medium sized project!

    It was in 1998 so maybe it has improved since then..(wishfull thinking)

  • So over time, if you've edited a 1k text file 100 times with 100 byte changes each time, you've got 10x the original size rather than just the previous version. Sounds like MSWord.

    If you only want the previous version, you can tell CVS to work that way, set the file type to binary and it'll only keep the most recent version. But if you're using CVS for backup only, then you're probably missing the point of CVS, which from your post I'm not sure weather you get.

  • Amen. Visual SourceSafe appeals to people who have a hard time with command lines, past that, it's terrible. CVS is so much better, and it's free.
  • SourceSafe is a decent product if you've got a fast network but it becomes extremely painful on slow networks.

    Our network here is fairly sluggish. On a project with about 500 files, SourceSafe would take 30 minutes to do a diff of the source (just see what was different between your local copy and what's in the archive).

    The same project in CVS takes about 3 seconds. Needless to say, we've fully switched over to CVS now for performance reasons.
  • Text DFMs were the final step needed to make Delphi the Best...Language...EVER.
  • Right, I know this is not free/OSS but its a good product nevertheless. Has anyone tried Rational Clearcase [rational.com]. Its great for really large projects and comes with its own FS to preserve space (Files can be in your view but if they arent checked out they are Read-only and only in the repository).
  • <flamevest mode="on">
    You must be on some form of crack.

    Visual Sourcesafe is not more reliable than CVS.
    Visual Sourcesafe is one of the most god awful version control softwares ever written. No client/server, shoddy file-locking, lousy performance, It's so damn bad that even Microsoft is discontuing it. (Amen!)

    VSS can be simple to use, but WinCVS makes CVS easier to use than VSS. Much easier to understand.

    Our entire development team took maybe 3 days to convert to CVS, and now not one of them would ever go back.

    </flamevest>
  • You may also want to look into Perforce. We use at where I work, and it seems like a very nice system (and it's got some killer features that VSS doesn't have; for one thing, Perforce knows what code has been updated since your last fetch, and will only return that, while VSS has to scan the entire tree in order to return the code; Perforce is significantly faster as a result).


    --
  • I'm not sure which part of your post if funnier. The part about VSS being more reliable and easier to use than CVS or the part about the Gnomes. IMO VSS might work well for one person to keep track of changes, but it's just so slow and so annoying that I'm glad my company decided to leave it behind. I really did not like the fact that it would tell me that a file was checked out on "G:\" wherever that may be on our network. Maybe it's just configured wrong out of the box, but it was a nightmare to use. I don't think it understood the difference between a client and server since it used path names as if they were all on the same machine.

    I've used CVS for work in the past and currently use it for non-career development, and it works much better that way. Plus it works much better than VSS did a) with geographically distributed clients and b) on multiple platforms.
  • I was working on a major e-commerce project a few years ago that was threatened by Visual SourceSafe gnomes. Time and time again, on different computers all sharing the same VSS repository, the 2048th character in a checked out document would be removed and placed at the end of the file. Gnomes if I ever saw them, and the instigator of quite a few 'who broke the build?' discussions... Gnomes aren't biased by platform or program. Watch out for them wherever you go!
    Kevin Fox
    --
  • Has anyone else noticed that the sheep on the right on the cover has three legs, and one of them is facing backwards?

  • No nutshell here (Score:3)

    by platinum ( 20276 ) on Tuesday March 27, 2001 @06:26AM (#337552) Homepage
    This doesn't appear to be 'CVS in a nutshell,' nor is it published by McGraw-Hill. In fact, this appears to be 'CVS pocket reference' by O'Reilly. Am I the only one confused?
  • Here at work ClearCase is a corperate standard, though on my current project our team is using CVS and then we (plan to) commit CVS changes back to a corperate ClearCase "VOB".

    We used ClearCase directly for quite a while. What I grew to dislike about ClearCase:

    * Difficult to delete or rename files (have to use cryptic command-line tools - what's the advantage of having a SCM file system if you can't really use it like a file system?)

    * Slow.

    * When you loose the licence server, all your developers are out of luck. Especially so if you were using the dynamic VOB, then you can't even see your source.

    Basically, I just found it incredibly annoying to use. I've used MKS (based on RCS) SCCS, Source Safe, and other systems... so far I think CVS offers the best solution to multiple developers working on code, especially the same modules of code.
  • PD opined:
    > c) I haven't mentioned clearcase. The less said about that horrendous mess the better.

    Why I love and hate ClearCase, in yin/yang pairs:

    + more scalable than any other system I know of
    - doesn't scale past ~100 users or ~5GB of data

    + MVFS is fucking beautiful ("vi foo.c@@/main/3")
    - MVFS makes me hack up my client kernel with a slllooowww, unstable filesystem redirector

    + Support for super-flexible, customizable attribute/value metadata
    - accessing said metadata is slow to the point of useless

    + support for multi-site (like a distributed database)
    - multi-site info is read-only and hence not too useful

  • Funny. I've never had a problem with CVS (except mucking up upper case or lower case on NT).

    I have no experience with Visual SourceSafe, but ClearCase is the best code repository tool I've ever used. It blows CVS out of the water for large distributed teams. Of course, it costs mucho $$$ and requires a dedicated administrator (or two).
    -------------

  • I'll put in two cents worth for Perforce [perforce.com]. The open source version of the BeOS Tracker [opentracker.org] uses P4 and it works pretty well, although it's not free.
    CVS, on the other hand IS free and it also works wonderfully. Good luck with that troll infestation at your office.
  • Opentracker.org was able to get a pretty good deal from Perforce. Be Inc uses P4 in house and I'm assuming they got permission to use it for open source development. Working on OpenTracker was my first exposure to Perforce, and I like it at least as much as CVS.

    Anyone can get anonymous, read-only access [opentracker.org] to OpenTracker for free and you can P4 sync, edit, diff and resolve all you want. Patches still have to be manually emailed, however. The only only users [opentracker.org] who can commit changes thru P4 are people who already have P4 seats because they work at Be, plus also Scott and Thorbjorn who don't work at Be but they're still l33t anyhow ;-)

  • I'm doing my dissertation on SCM software, so I've done research ;)

    I don't like CVS; this is my own opinion and I'm saying so now, so don't flame me :) . The unreservered checkout model is a pain with any project larger than the average GPL hobby-kit. The more programmers you get the more merges need to be done. A merge requires knowledge of all changes under consideration, so the person merging needs knowledge of the entire project. As the goal of an SCM is to distribute the work, it is a failure in this situation.

    I think locking is a better model. In my SCM, I'm allowing locking of individual functions/classes by clients. In addition, CORBA networking and XML-based storage are features.

    Thanks for the bullet points, Node renaming was on my early lists, but I had forgotten it. :)

    Personally, my favorite so far has been sablime( Link [bell-labs.com]; rigid locking, SQL queries and can handle HUGE teams and documentation.

  • Deadlock shouldn't be a problem with a query system and inter-programmer communication.

    If you're 'merging' together a product your going to get a quite a number of end-zone bug fixes. In a ticket based system like sablime, all recognised bugs are trackable to conclusion. This is partly because of locking.

    In a merge situation, you have to wait for any outstanding development to find out if the bug fix was successful. To me, CVS seems like the half-assed solution.

    In the projects I've worked on, I haven't found locking to be restrictive at all. The one time I wanted access to a file someone else was using, I emailed them and was working on the file by the end of the day. (This was over 9 months of interrupted work - holidays :) .)

    I agree entirely about the binary data files. You've got me thinking about plug-ins now. :)
  • Agh. Directory and file renaming ALONE is the reason I don't use it for managing small or medium-sized projects.

    That, and I wish I had a script for automatically handling commits from a small group of people for whom CVS is overkill, solely so I can track changes and back out of them day-by-day. This script would have to look through files and directories and intelligently handle renames, too. This is possible for text files at least, but I don't have a week to spend writing the script.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.

  • I don't agree that CVS sucks, but this review certainly does.

  • CVS Reference Card (Score:4)

    by ljavelin ( 41345 ) on Tuesday March 27, 2001 @06:22AM (#337562)
    You can also get a PDF-formatted CVS quick ref card at http://www.refcards.com/ [refcards.com]
  • CVS in a Nutshell, publisher McGraw-Hill

    Actually, it's CVS Pocket Reference [oreilly.com], from O'Reilly.

  • Re:Use Visual SourceSafe (Score:3)

    by cyberdonny ( 46462 ) on Tuesday March 27, 2001 @06:41AM (#337564)
    I'd be more concerned about the very real disk full problems that can show up in Visual Source Safe, than about the mythical CVS gnomes that eat your lunch.

    If you don't carefully monitor the available disk space, and regularly take backups, you may suddenly encounter the interesting situation that all your repository is trashed, because VSS is not able to correctly deal with low-resource conditions.

    Plus, VSS's command line interface sucks, which makes it somewhat hard to interconnect VSS with other programs such as Emacs' VC mode.

  • disappointing book and overpraising review (Score:3)

    by Prestissimo ( 54063 ) on Tuesday March 27, 2001 @06:50AM (#337565)

    I hardly think this book deserves a rating of "8". The reviewer is correct, that the organization is poor, but that is an understatement.

    It tends to organize in a most-global to most-local fashion, but in doing so, it highlights the least frequently used information before the most frequently used info.

    The section called "User Reference" is arguably the most frequently used. But it is placed at the end, and is difficult to get to. It starts by listing all the environment variables that might apply to CVS, rather than describing the common commands and options. Furthermore, once you finally get to the description common commands, it is little more than a printout of typing cvs --help [command].

    The first 2/3 of the book covers server-side tasks and focuses on one-time setup issues, like compiling and installing the program.

    If someone wants to use this book as a quick reference, that organization is completely backwards.

    Even the layout is lacking. There are many places where a page break would greatly help the readability. But instead, the layout is one long flow. (Even the major sections listed in the TOC don't start on a page break.)

    Overall, I am disappointed with the quality of existing CVS documentation, and this book is no help. It doesn't present common tasks in a clear and enlightening fashion. It has little information on some of the more interesting use cases that show the power of CVS. I now rarely use the book because it takes to long to flip through to the section I want. Instead, I rely on CVS's online usage info. Hopefully a revised version will improve on these weaknesses.

  • > You may also want to look into Perforce.

    We use it here too, and have folks working from home who are happy with it. It's commercial, however, whereas CVS is, of course, free as in beer and speech. (Of course, if you're considering VSS, hey, that's commercial too :-)

    On the scalability side, I haven't seen too many problems with CVS as things got bigger. Speaking for myself, I'd look at Perforce, but if it's already been decided From On High that it's gonna be either CVS or VSS, I'd go with CVS.

  • Has anyone had success communicating with CVS Gnomes? If so, how did you do it? They seem to be afraid of me :(

    I've found that a little hacking of the commitinfo file and a large hammer keep the little fu^H^H^H^H^H^H^H^H^H developers^H^H^H^H^H^H^H^H^H^H CVS Gnomes in line.
  • CVS lacks a few features that make it really uncomfortable to work with.
    -atomic checkins on multiple files: basically meaning that you can't really tell what files came in with each checkin, so backing out of a change is a chore, also it's possible to checkin
    only a part of what wanted to (if the network goes down) resulting in a broken tree
    -file renaming breaks file history
    -no directory renaming
    -no disconnected operations on the repository(e.g. checking the file history when you are on a laptop in a plane)
    -branching and multiple merges back into the trunk is a little awkward
    -setting up a staging area for integration of changes is similarly awkward

    The alternatives:
    Bitkeeper [bitkeeper.com] looks really nice, I've only played with it though, not used it in any serious development. It follows a model that every developer gets his own repository, and then push changes around these repositories. The license allows access to the source code, but is not quite open.

    A lot of people like Perforce [perforce.com]. I don't have much experience with it myself though.

    Visual SourceSafe [microsoft.com] is slow over the network, seems to corrupt files easily, and not so friendly cross platform. It has a nice GUI, if you are into that kind of stuff. Has similar problems with CVS regarding branching and atomic transactions.

    ClearCase [rational.com] is really expensive(in computing resources, money, and adminstration costs). On the other hand it has nice integration with rational's workflow and bug tracking products.
  • > Delphi ... files ... are binary

    Nope, they aren't. .pas and .dpr files are text.

    So are .dfm files from Delphi 4 onwards if you turn that option on (ie if you have any sense).
  • > Visual SourceSafe is much more reliable

    Visual SourceSafe ... reliable ... bwhahahaha!! That would be so funny if it didn't bring back painful memories.
  • Horses for courses. However, for what I do, day to day, Delphi is the best yet.

    What is needed to make delphi better? Kylix, more MPL'd components & functions a www.delphi-jedi-org, freeware VSS/CVS integration pluggins, etc ... but that's getting off topic.
  • Personally, I like CVS, but one thing I wish it did handle was recording in the metadata whether a file was CR/LF translated on checkout or not.

    I am in the unfortunate position of having to do development under Windows and Linux, and if you check out a source tree with the Windows port of CVS, all your text files have LF->CRLF translation applied. If you then try to check them in from Linux, the Linux CVS client will NOT strip the CR's out, and every line of the file is "touched".

    Worse yet, if you then check them back out under Windows, you get CRCRLF...

    Yes, it would be nice if I didn't have to do this sort of thing. It would be nice if I had a million dollars and didn't have to work for a living, too.

  • No atomic operations? That does not agree with my experience: if I do a "cvs commit" on a directory, all the files go in at once or they don't go in at all.

    Directory renames I'll give you. It would be nice if CVS would allow file/directory renames.

    Disconnected checking? This only tells you what the state of the system was when you last updated, i.e. when last you checked out. How is this much better than CVS?

    Setting up a staging area is awkward? How so?

    mkdir integration
    cd integration
    cvs checkout
    cvs update -j mybranch
    cvs update -j hisbranch
    ...
    make
    test
    cvs commit -m "Merged mybranch and hisbranch"


    Could you give a little more detail?
  • If you're in a linux environ (well you probably already are using cvs!) save yourself a few dollars (with all respect to my friends at O'Rielly) and type info cvs. Hard to beat it.
  • click here [cvshome.org] then.
  • Has anyone had success communicating with CVS Gnomes? If so, how did you do it? They seem to be afraid of me :(

    I had CVS Gnomes once. Noisy little critters, too. They kept clamoring on and on about "underpants" and "big profits". I finally managed to lure them away with a 3-pack of cotton briefs.

  • You could try "pinfo" if you dislike info...

    Just an idea... maybe you already tried pinfo too..?


    --
  • Actually, it looks to me like timothy misattributed the article; in the credit box it says "reviewer Craig Pfeifer".

    I don't think Purdy actually had anything to do with this review (other than having written the book).

  • I have used both Perforce and CVS. I must say that overall I like Perforce better. One thing that it has over CVS is that changes are atomic, which is nice becuase it is easy to see all changes which were checked in together, and lets you backout changelists atomically, should you need to.

    I am not using perforce now because it is too expensive, however Perforce is free when used on open source projects, or when only two clients are needed. This is outlined on the perforce pricing page [perforce.com].

  • It's in the latest VS.Net beta as standard. I haven't used it though, what reason do I have to think that a beta version of the new VSS will work O.K. when the production version of VSS in the last version of Visual Studio didn't?
  • The book shown is actually CVS Pocket Reference [oreilly.com].

    It seems strange that that author of the book would not know its correct title. Worse, there's no real disclosure of his connection to the book.
    --

  • Actually I find WinCVS *OK* but it's UI is horrid. I usually end up using the command line it's so bad. For most day to day things that I do in CVS I find Tortoise [wincvs.org] CVS to be far better. It integrates well with Windows Explorer and you can perform most CVS tasks by just selecting things in explorer and right clicking. It's pretty spiffy and it's actually based on the WinCVS code base.
  • While we're on the subject of CVS...
    I've gotta plug cervisia. It's a Very nice GUI for CVS. One of the features I really like is that it will show you the command line it executes so you can learn the commandline from the GUI. A very nice blend of useability & power.

    Check it out at:
    http://cervisia.sourceforge.net/

    Eli
  • You should correct the title and publisher of this book. I have one on my desk, and it says. "CVS Pocket Reference" *not* "CVS in a Nutshell", and it is published by O'Reilly, which hopefully would be obvious by the appearance of the ever- present animal cover..
  • Wow! Thanks everybody for those great responses.

    While our hands aren't tied as far as VSS vs CVS vs others, we are (very much) tied to Windows NT. I'm curious to try Perforce out. Their web page promises much, and your references seem to bear that out.

    Thanks again,

    John

  • Re:Use Visual SourceSafe (Score:5)

    by plover ( 150551 ) on Tuesday March 27, 2001 @06:36AM (#337587) Homepage Journal
    Unfortunately, we suffer from PVCS Trolls in our office. They're little creatures who administer our PVCS server and arbitrarily deny rights to all and sundry.

    On the plus side, the PVCS Gnomes are still hard at work, damaging about one file in every 5000 checkouts. Since we have a 2100 file build at the moment, that's one in three builds getting trashed by this worthless system. We hope this is enough ammo to have PVCS shot, drawn and quartered, and sent to the Eastern front.

    We've been considering both Visual Source Safe (which we've had good luck with, but find it feature-poor) and CVS. I'd love any feedback anyone has comparing the two on a fairly large project, particularily where we have two sets of developers working off-site through slow IP links.

    John

  • If you're using windows and Visual C++, I'd recommend using Microsoft Visual SourceSafe. Why? Because it's easier to set up and use, and for single person projects, it'll work fine (even though there is the big problem of not being able to work on concurrent version of a file, although this may have been changed/fixed in current versions). And to boot, it's easier to administer and setup, with a standard windows gui.

    Anyways, I hope this helps! Cheers,
    Chris
  • http://www.oreilly.com/catalog/cvspr/ Are you sure you're revewing the right book?
  • While I like CVS quite a bit more than VSS, your impressions of VSS are a touch out of date -- the version of VSS I've used at work (we use both, depending on the project and where/what it's going to be hosted on) is client-server, has better permission control (ACL's all the way) than CVS without -major- hacking, and it's directory browsing (without checking the whole tree out) is rather useful (though CVSweb will give you something similar).

    OTOH, CVS is -far- more configurable, is cross-platform in a way VSS can't match, and is far, far better for teams (you know, like when you want to -not- have a file locked for hours on end just 'cause someone's recoding a single subroutine in it? And with a cron job keeping our development environement in lockstep with CVS, testing on the live box gets rather clean.
  • Thanks! You know, I discovered the Info system years and years ago (that would be '91, back when it was going to take over the world, and before the web started really taking off and HTML started blowing info's hypertext out of the water), and given the amount of stuff that -isn't- on it, it didn't even occur to me to look up the info page for CVS...I want a unified documentation system, whether it's info, or html, or man, or POD, or /usr/doc/, or whatever, but -something- nice and browsaable I can translate everything into; as it is, the documentation for everything is so spread out you need to Ask the Fucking Question before you can FTFM, much less RTFM.
  • We've been considering both Visual Source Safe (which we've had good luck with, but find it feature-poor) and CVS. I'd love any feedback anyone has comparing the two on a fairly large project, particularily where we have two sets of developers working off-site through slow IP links.

    My company recently switched over from VSS to CVS. We several large products, with many files. I don't think any one project has 2100 file but combined we're well over that.

    I personally love CVS. Multiple people can edit the same files and merge them back (A HUGE GAIN). You never get files locked by someone.

    But the biggest gain is the tools. CVSWeb is great, you can browse your code in a web browser, look at diffs between checkins, annotate those diffs, the whole nine yards. CVS and LXR work together very well. LXR isn't the single greatest coding tool I've ever used. All of your class's, variables, header files are all cross linked, navigating code is easy. Use glimpse and searching is easy. Bonsai makes watching the build easier (but I havn't used it enough to be really pro or con).

    We had issues with VSS stability. That may or may not be our fault. On features alone CVS is much better than VSS.

  • So over time, if you've edited a 1k text file 100 times with 100 byte changes each time, you've got 10x the original size rather than just the previous version. Sounds like MSWord.

    There's no B(ackup) in CVS.

  • But if you're using CVS for backup only, then you're probably missing the point of CVS

    That's what my last sentence said. Using CVS for backup at all is riduculous. There are tools meant for that.

  • This is just the kind of thing for which safari [oreilly.com]. Is perfect. I'm talking work into paying for an account right now.
  • No atomic operations? That does not agree with my experience: if I do a "cvs commit" on a directory, all the files go in at once or they don't go in at all.
    Not always. Think server crashes, databases, and ACID tests [arsdigita.com]. But here's the more important side of atomic checkins.

    One day I add a superfoo() function to foo.c and foo.h, making revision 1.37 of foo.c and 1.22 of foo.h.

    Three months later, I am looking at foo.h, which is up to 1.57, and I want to find out everything about the changes that introduced superfoo(). With CVS, as far as I can tell, I look at foo.h's log, see the checkin comment that added superfoo(), hope that the same comment might appear in foo.c's log, but probably have to correlate the two via the ChangeLog file. It's harder when there's not something simple like "superfoo()" to grep for.

    With a system with atomic checkins, I look in foo.h's log for the relevant global change number, and then I ask what effect that change number had on foo.c. No manual searching.

    It seems to me that the sole reason why GNU projects labouriously maintain ChangeLog files is to cover for the lack of atomic checkins and reporting functionality in CVS.

  • We've been considering both Visual Source Safe (which we've had good luck with, but find it feature-poor) and CVS. I'd love any feedback anyone has comparing the two on a fairly large project, particularily where we have two sets of developers working off-site through slow IP links.
    In previous lives, I've used in earnest RCS, PVCS, CVS, and VMS's CMS. Thankfully I was never subjected to Source Safe.

    PVCS was appallingly bad. Random corruption, files perpetually locked by others. RCS was feature-poor. CMS was actually pretty good, especially if you didn't want to branch anything. I used to like CVS.

    Then I landed in a shop where they use Perforce [perforce.com], and grumbled for a while that it wasn't CVS. Pretty quickly I was a convert. Perforce is like CVS except that:

    • branching is understandable
    • the commands and options are regular and systematic, so it's possible to remember what they all do
    • it has lots of reporting commands, so you don't have to maintain a ChangeLog by hand

    Then I discovered how much fun scripting it was!

    There's tension in that it's not free software, but then Perforce the software and Perforce the company are a joy to deal with, so you don't begrudge them all that much. Their user base is largely a free software-like rabid bunch of happy advocates, so something must be right.

    I'm looking forward to next week's SVLUG [svlug.org] talk about Subversion [tigris.org], which might be Perforce's first real competition for a while in the "it's not ClearCase -- thank God" category.

    Over the slow IP links: by all accounts, Source Safe is terrible. On our large projects worked on from half a dozen sites, Perforce works well. The GCC folks can probably tell you how well CVS works in that situation: I suspect the answer is pretty reasonably well too.

  • But nothing beats the older version that we're learning in college right now. What is it? RVC?
  • Here's the real link for CVS backups [cvs.com]. Enjoy!

  • I only use CVS as a backup if my local Rx is closed.

  • The single best feature of ClearCase is correct support for renames and relocations. No other system allows one person to reorganize a whole source tree and still keep the history of every element intact.

    The value of this is vastly underestimated. Just imagine not having to spend so much time figuring out the initial layout of the tree, since you can modify it as the project evolves. Just think of all those crappy class hierarchies that only exist because reorganizing the source tree is such a hassle, and just look at the contortions tools like VC++ go through to enable developers to reorganize their prohects without moving the files - all because renames are tough to do in any system but ClearCase.

    As for all the other perceived and real flaws, they all can be dealt with by a competent ClearCase guru (like me).

  • The problem with going behind the scene is that your changes will affect everybody, instantly.

    The point of having versioned directories is that you can go about your reorganization at a leasurely pace, keeping in synch with all the other people, test it and then commit it and have your other developers absorb the change at their leasurely pace.

    The only system I know of that can do this is ClearCase. Yes, it is a complex system that requires a very competent admin (like me), but then, I can do things with ClearCase that would be unthinkable in any other system

    See http://www.miaow.com/clearcase/ [miaow.com]

  • I really disagree. Locking is a half-ass solution and almost invites the deadlock situation.

    There is no way to avoid the merge if you really want to have an open-minded but efficient parallel development environment. The scaling up is done by organising "delivery streams" and merging them into the final product. Of course you try to avoid overlap by good software design and by dispatching tasks properly, but you don't outlaw overlap via locking.

    The really unfortunate side of current software development environments is that they produce more and more binary data files that are not mergeable and essentially punt on all the hard problems...

  • VSS is horrible at branching, an inconsistent directory syntax and a truely terrible command line interface. The last characteristic makes scripted builds a nightmare to implement.
  • My group recently switched from VSS to CVS and have fairly good luck. I'll echo that it's more tool rich. To be fair, a few of us invested some time in filling in different facilities we wanted but the basic tools made these mainly adjustments. For performance VSS was maddening slow in our project (~60 directories, ~750 files) even with DSL. CVS seems much better in this regard and even supports compression (-zN option) if you require more. On CVS so far we've only had two incidents where odd things happened and both were recoverable without loss of data (one was a file incorrectly marked as 'locked').
  • Check out the CoriolisOpen Press book "Open Source Development with CVS" for an excellent reference to CVS.
  • Someone mentioned that CVS barfs on Windows/Unix synchronization, since the CRLF issue makes it appear that every line has changed. This is in conjunction with the Windows CVS client.

    You might want to take a look at the Unison [upenn.edu] file synchronization mechanism.

    I use CVS on my Unix boxes, and keep my Windows laptop synchronized with Unison. I synch to my main development Unix box. The chain looks like this:

    Repository <-cvs-> Unix box <-unison-> Windows laptop
    Thus my Windows mods are synched to the Unix box, and checkin/out is only done on the Unix box.
  • The best place I have found for a CVS reference is their own web page manual [cvshome.org]. Everything you would want to need and printable too! I spent one day reading the entire thing and I'm very confident with CVS now.
  • Vanessa: Maintaining multiple versions of source code in a distributed project, that's you in a nutshell.
    CVS: No, this is me in a nutshell; "Help! I'm in a nutshell! What kind of nut has such a big nutshell? How did I get into this bloody great big nutshell?"
  • Maybe I'm missing something, but this article just seems to lack significance. Except for the point about organizing by client/server, rather than user/administrator, the review says nothing non-obvious. "It's a good pocket reference, except that I think the material should be organized by client-side and server-side, rather than by user/administrator." That's it.

    On the positive side, this may motivate me to investigate using CVS.
  • That's the shortest review I've ever seen on here, and it's *still* wrong; now, this is CVS in a nutshell:

    Help, help, I'm in a nutshell!

    CHECK ME OUT OF HERE!
  • I agree. I doubt there is anything in it that cvs --help [command] won't tell you.
    ---

  • Use Visual SourceSafe (Score:3)

    by JAVAC THE GREAT ( 239850 ) on Tuesday March 27, 2001 @06:28AM (#337613)
    Visual SourceSafe is much more reliable and easier to use than CVS. Plus, you do not have the problem of "CVS Gnomes." CVS Gnomes are little creatures that live inside CVS repositories and mysteriously undo changes to your code, or break previously working code.

    I personally have seen CVS Gnomes in my office, but upon attempting to communicate with them, they flee in fear. I do leave little pieces of cheese for them by where the ethernet goes into the wall, though, and I notice that every night they do not fail to eat it.

    Has anyone had success communicating with CVS Gnomes? If so, how did you do it? They seem to be afraid of me :(
    ---

  • Why buy a book when a very good online manual is [on the web]? The answer is fairly obvious, but you have to Read The Review:
    1. The documentation you link to is another copy of the canonical documentation, in an only slightly different form than that behind the link in the review. Both are based on the gnuinfo-formatted documentation that comes with cvs (and can be easily read off-line with products such as tkinfo [uni-paderborn.de]). This documentation has proved for me to be quite sufficient for most day-to-day CVS questions.
    2. But, as the review points out, there are some things which are not well explained in the canonical documentation. These basically involve serious repository restructuring and/or repair. You rarely have to do these, but if you do them wrong, your repository will be seriously damanged if not totally kaput.
    I haven't got a copy of the Pocket Reference, so we'll have to take the reviewers word for it that these things are well explained in the book. However, it boils down to this: on the one hand, you're right, for the day-to-day stuff, the canonical documentation is quite sufficient (although I suggest reading it off-line to save bandwidth). On the other hand the reviewer did plainly state that the book is interesting because of the extra information it provides.

    Ron Obvious

  • The block of book info up top says the publisher is McGraw-Hill, yet the cover of the book looks extremely critter like. Very critter like. Like, like, O'Reilly perhaps? I thought so.

  • There's also this very good book online (Score:4)

    by Lobsang ( 255003 ) on Tuesday March 27, 2001 @07:04AM (#337617) Homepage
    You can find a good part of the Open Source Development With CVS book by Karl Fogel online at http://www.red-bean.com/cvsbook/cvsbook.html [red-bean.com]
    It's a very easy to read CVS book that begins with the basic steps of creating a repository and goes all the way to cover a lot of advanced aspects about using CVS on a daily basis.
  • Chora [horde.org] provides an aesthetically pleasing PHP-based web interface for CVS. Here's a zip file for download [pixeldate.com].
  • if you use cvs to backup any information on your network, it means that you don't need to transfer entire files about - just diffs of the files that have changed, greatly reducing network strain.

    i was angry:1 with:2 my:4 friend - i told:3 4 wrath:5, 4 5 did end.

Slashdot Top Deals

/earth: file system full.

Close