[olug] CVS

Fri Sep 12 20:18:58 UTC 2003

I'm just starting to look at CVS, and that got me thinking....

Would this be a good topic for someone to present at the next
OLUG meeting?

Christopher Cashell said:
> At Fri, 12 Sep 03, Unidentified Flying Banana Craig Wolf,
> said:
>
>> Ok, pardon my ignorance.  What is CVS, where do I get it
>> (freshmeat?), what does it do for me?  Tracks changes in
>> files I tell it to watch?? I am trying to understand.  I am
>> still standing on the edge of this ocean and I am only up
>> to my ankles so far in crossing it.
>
> CVS is the software package, the Concurrent Versions
> System[1].  It is built on top of the concepts from Revision
> Control System (RCS), and it is a type of Source
> Configuration (or Control) Management (SCM)
> software.
>
> Basically, every time you make a change to a file, you
> 'check in' the changes, and they are recorded.  In this way,
> any changes you make can be reversed and tracked.  The most
> common use for these types of systems is in software
> development and programming.  By keeping your source code in
> something like CVS, you can make it *much* easier for
> multiple people to each be working on the same software.
>
> Here's a quick and dirty example. . . say I'm writing a
> program called 'foo'.  The first thing I do, is take any
> source code files (and other related development files) and
> put them into my CVS system.  I do that by creating a CVS
> repository and importing everything I currently have.
>
> Then, every time I make changes to any file, I check in the
> changes, and the changes are recorded in the CVS repository
> (as a diff, basically).
>
> Additionally, since CVS is network transparent, and can be
> used as a client-server system, I don't have to work on it
> at a single location. Once my changes have been checked into
> the CVS repository, I could then go to another computer,
> check out the entire source code set, and work on it there.
> If I then make changes, and check them in, I could later go
> back to my original computer and update my local code to
> match the 'current' code that is in the CVS repository.
>
> Through this way, by having a central repository that tracks
> all the changes, but having multiple "working" copies
> checked out, many people can all be working on the same
> code.
>
> You can also tag sets of files and versions as a set.  For
> example, if I'm working on foo, as mentioned above, and we
> hit version 1.0, I could tag the CVS repository to
> foo_release_1_0.  Then, even if we work on the program for
> two more years, if I get a sudden desire to see how the code
> looked at version one, I could retrieve it by simply getting
> all the files that have that tag, at the version tagged.
>
> And, as you can probably imagine, the software works great
> for any files that change frequently.  I keep all of /etc in
> CVS, and every time I make any changes, I check in those
> changes.  If I make really big
> changes, for example, moving from Apache 1.x to 2.x, I even
> tag the httpd.conf, since there are major changes to it, as
> apache_1_last_config.  Then, if six months from now I decide
> to suddenly go back to Apache 1.x, I can easily retrieve
> that specific version of the file.
>
> If you ever change a conf file, and accidentally make a
> change that breaks it, and the program won't start, you
> could be in a bad spot. Especially if you made a lot of
> changes, and don't know where it's broken at.  In this case,
> it would be easiest to just pull out the last checked in
> version of the file, and use that, while you play with the
> new one.  Same thing if you accidentally delete a conf file.
>  You can simply pull the last checked in version from CVS.
>
> I'm not sure if I'm doing a very good job explaining this. .
> . I've been using CVS intensely for so long that I may not
> be the best person for this.  However, there are a number of
> great resources available for it.
>
>  * There's the Cederqvist manual[2], which was written by
>  Per
>    Cederqvist et al, and is the "official" CVS manual.
>  * There's the CVS FAQ-O-Matic[3], which contains a lot of
>  great Q&A for
>    CVS.
>  * There's the book, "Open Source Development with CVS", by
>  Karl Fogel
>    and Moshe Bar.
>    - The first edition[4] is almost entirely freely
>    available, and can
>      be found online.
>    - The newer Second edition[5] is also available, but only
>    in PDF
>      format.  If you don't mind PDF, I'd suggest it, as it
>      has a little more information in it.
>
> My suggestion would be to start with the Second Edition of
> the CVS book (the PDF), but any of those should be able to
> provide you with more information.
>
> As for getting CVS, most distributions include it either by
> default, or as part of their "development tools", if you
> install that.  On Debian, it's as easy as 'apt-get install
> cvs'. ;-)
>
> If you can't find it as part of your distribution, you can
> get it from their homepage, which is referenced in this
> e-mail.
>
>> Thanx to any and all for replies!
>
> Hope this helps. ;-)
>
> If you have any other questions, or would like a better
> explanation of how I set up /etc in CVS, let me know.
>
>> Craig Wolf
>
> [1] http://www.cvshome.org/
> [2] http://www.cvshome.org/docs/manual/
> [3] http://ccvs.cvshome.org/fom//cache/1.html
> [4] http://cvsbook.red-bean.com/cvsbook.html
> [5]
> http://cvsbook.red-bean.com/OpenSourceDevWithCVS_2E.tar.gz
>
> --
> | Christopher
> +------------------------------------------------+
> | A: No.                                         |
> | Q: Should I include quotations after my reply? |
> +------------------------------------------------+
>
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> http://lists.olug.org/mailman/listinfo/olug

_________________________________________
Mac Petras
Mac at PetrasWeb.com