What exactly is CVS and how can I use it to my advantage
Moderator: General Moderators
What exactly is CVS and how can I use it to my advantage
I couldnt find any other forum to stick this in, so here goes:
Im in the process of creating a Java based application. I want to make the development and distribution process as easy and professional as possible. Ive been hearing many things about CVS, but i just dont understand it, and frankly, i dont know if its what i need
Ive read mainly the wikipedia section on CVS.
My main question is, how can I use CVS to ditribute my product, and what programs, or utilities do i need to make it work?
sorry if this is a stupid question
Im in the process of creating a Java based application. I want to make the development and distribution process as easy and professional as possible. Ive been hearing many things about CVS, but i just dont understand it, and frankly, i dont know if its what i need
Ive read mainly the wikipedia section on CVS.
My main question is, how can I use CVS to ditribute my product, and what programs, or utilities do i need to make it work?
sorry if this is a stupid question
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
CVS = Concurrent Version System(s)
it's version control.. and quite outdated too. I recommend subversion if you have a choice.
It's mostly for development usage. As for distributing, it can be used, but only dev builds typically. (Like a nightly build)
it's version control.. and quite outdated too. I recommend subversion if you have a choice.
It's mostly for development usage. As for distributing, it can be used, but only dev builds typically. (Like a nightly build)
Re: What exactly is CVS and how can I use it to my advantage
That description fits Version Control Systems in general. They are a method that allows a distributed team (ie, not sitting next to each other) to collaborate together on a single codebase.Deemo wrote:I want to make the development and distribution process as easy and professional as possible. Ive been hearing many things about CVS, but i just dont understand it, and frankly, i dont know if its what i need
An example:
In my spare time, I code a game. The game has multiple files. One of the files is global_includes.php. That file interacts with much of the game.
I need to make a change to it. Using cvs, I download a copy of that file (cvs checkout). I then make my changes, and save them locally. Then I upload the changes to the central repository (cvs commit).
While I'm doing that, Bob decides he wants to add a nice professional header to global_includes.php. He also does a checkout. He also makes his changes. He also wants to commit. Whats the right behavior?
In CVS, it handles things at a per-line level. It sees that I've made changes in lines 100-200, and accepts those. Then it sees that Bob has done changes only from lines 0-20. Since there is no conflict, it merges the changes together.
If it can't figure it out, it refuses to 'commit', and tells you there is a conflict, and that you have an out-of-date copy. Then you manually figure it out.
In a nutshell, it lets Bob and I work together, and not against each other.
CVS isn't really suited for distribution in that sense. Granted, if you put up a public CVS, you can in fact point people to it, and they can do an anonymous checkout (if you allow it). That way, they can use the very latest version you are working on.Deemo wrote: My main question is, how can I use CVS to ditribute my product, and what programs, or utilities do i need to make it work?
Its more common to use CVS to develop, and then when the 'tree' is stable, you made a package (zip, tar, gz) with the contents of CVS, and that is your release that you distribute.
As to utilities, it depends on your platform. Windows uses very different tools from Unixes.
Also, its important to know that there are alternatives to CVS that in many cases are better! Subversion is fantastic, and removes much of the pain from CVS. Arch is a completely different approach, with some great benefits, and some oddities that you could consider a plus or a minus. There are others as well.
The point being, if CVS (or any other Version Control System) has problems, dont judge ALL VCS' based on that.
There are no stupid questions, only stupid answers. For example, answering this question with "Purple" would be a stupid answer.Deemo wrote:sorry if this is a stupid question
PURPLE!
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Wait... I was going to spend a lot of time learning how to use CVS. Why is subversion better?feyd wrote:CVS = Concurrent Version System(s)
it's version control.. and quite outdated too. I recommend subversion if you have a choice.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
oops.. posted the wrong url. Correct one: http://subversion.tigris.org 
Subversion wrote:The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license.
Subversion's Features
* Most current CVS features.
Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.
* Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files.
* Commits are truly atomic.
No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file; log messages are attached to the revision, not stored redundantly as in CVS.
* Apache network server option, with WebDAV/DeltaV protocol.
Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, path-based authorization, wire compression, and basic repository browsing.
* Standalone server option.
Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x). The standalone server can run as an inetd service, or in daemon mode, and offers basic authentication and authorization. It can also be tunnelled over ssh.
* Branching and tagging are cheap (constant time) operations
There is no reason for these operations to be expensive, so they aren't.
Branches and tags are both implemented in terms of an underlying "copy" operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.)
* Natively client/server, layered library design
Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications.
* Client/server protocol sends diffs in both directions
The network protocol uses bandwidth efficiently by transmitting diffs in both directions whenever possible (CVS sends diffs from server to client, but not client to server).
* Costs are proportional to change size, not data size
In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place. This is a property of the Subversion repository model.
* Choice of database or plain-file repository implementations
Repositories can be created with either an embedded database back-end (BerkeleyDB) or with normal flat-file back-end, which uses a custom format.
* Versioning of symbolic links
Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies.
* Efficient handling of binary files
Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
* Parseable output
All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.
* Localized messages
Subversion uses gettext() to display translated error, informational, and help messages, based on current locale settings.
Feyd's post does a good job of a high-level answer. I'll cheat and copy and paste a recent email to my dev team about why SVN was specifically better than CVS in a recent development issue:Ambush Commander wrote: Wait... I was going to spend a lot of time learning how to use CVS. Why is subversion better?
----
The functions and classes directory have been combined to become the includes directory.
Here's what I did in SVN:
svn move functions includes
For CVS:
mv functions includes
cvs remove functions
cvs add includes
cvs ci -m "renamed functions to includes" functions includes
Subversion maintained all of the previous change information, CVS
doesn't. Subversion handled the filesystem changes. CVS doesn't.
Advantage: SVN.
Version control is very useful, even in one-man projects.
It lets you easily get back a previous version (for bug hunting) or for "I know I used to do it that way, how'd that work" type of questions.
P.S.: Octarine!
It lets you easily get back a previous version (for bug hunting) or for "I know I used to do it that way, how'd that work" type of questions.
P.S.: Octarine!
Last edited by nielsene on Mon Aug 22, 2005 5:45 pm, edited 1 time in total.
Need, no. Want, possibly.Deemo wrote:thanks alot for the responses. So if i have just a one man team for my project, CVS or subversion are not something i need?
I use SVN for all my projects, because it allows me to easily back out changes when I find a bug. Instead of keeping a backup copy for every change I make (HA!), I can just commit, and if there is a problem, I can revert to a previous version.
Its also useful for keeping track of WHY you made a change. Lets say a loop isn't working right, and you remove it because it only has problems on OpenBSD. Thats something you wont remember, and that documenting in code might be a bit too much. So, you document it in the commit message.
Its really very powerful and useful - even for one person teams.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Sure you can.Ambush Commander wrote:Ah, I can't use subversion because I run a Windows system.
TortoiseSVN is a Subversion client, implemented as a windows shell extension.
Tada.
You can also use Putty for ssh-svn, for the win.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Well, you can get those too.. if you want one free, you need to do an opensource project, and apply at http://gna.org .Ambush Commander wrote:Yeah, but I don't have a Subversion server to work with.
If you want to do closed source, you can pay for hosting at http://wush.net/subversion.php , or any of the hundred+ sites that come up when you google "Subversion hosting".
Seriously, try searching a little and complaining a little less.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Ugh.Ambush Commander wrote:Yes, but my point is I can't have a local copy to noodle around with unless I get a *nix based system installed.
Absolutely, totally the last time:
http://svnbook.red-bean.com/en/1.1/svn- ... h-1-sect-5
So yes, even if you really want to be COMPLETELY over the top, and have 100% of the entire solution, from client to repository, running on your home PC, you can.Subversion is built on a portability layer called APR (the Apache Portable Runtime library). This means Subversion should work on any operating system that the Apache httpd server runs on: Windows, Linux, all flavors of BSD, Mac OS X, Netware, and others.
Search. Before. Complaining.