News
	Latest
	Archive
	Community news

Articles
	C++
	Communities and Content
	Databases
	Editorials
	Emacs
	General
	HTML
	Java
	Notices
	PHP
	XML

Links
	Apache
	C++
	Database
	General
	HTML
	Java
	Javascript
	Linux
	Object oriented programming
	Open source
	Perl
	PHP
	Python
	Ruby
	SOAP
	XML
	Suggest a link

About
	Advertise on zez
	Contribute
	Contact us
	About zez

Version Control management with CVS - Part 2

Author: Jan Borsodi

Publishing date: 24.11.2000 11:33

CVS is a Version Control System which helps multiple developers manage software projects. In this second part I'll show the basics of committing your changes to a project, adding new files, creating patches and explaining version numbers. For those of you who missed the first part you can read it here.

Comitting

Committing, the second of the two widely used CVS commands (the first is updating), takes care of sending all your local changes to the CVS repository. To be able to commit your changes you need write access to the CVS repository, so any anonymous logins won't work.

Before I start explaining the commit command I'll tell you a little secret that will make your committed work so much more appreciated. The scenario is this.

You're working on a project and have successfully enhanced it by adding your own super code locally. You've tried out your personal changes several times and everything seems to work OK. Now you probably want to send these changes to the repository so you perform the commit command. However while you were busy creating your changes somebody else has done some other changes to the project which directly affects your work. If you were to commit you changes as it is now one of three things could happen:

1. No conflicts or compile problems occur for other co-developers.
2. No conflicts occur but the code will not compile with the latest CVS version.
3. Conflicts occur because you and one or more co-developers have modified the same code lines as you.

If number 3 happens you won't be able to commit because you don't have the latest version, and you cannot commit a lower version over a newer version, this means you have to update your local CVS repository.
Number 1 is harmless since it works for all parts, but number 2 is something you want to avoid since it might break code. So how do you avoid number 2 you ask?

As a rule of thumb you should always, and I mean always, update before you do a commit. Why so? Well if you have the latest version locally and your new code still works, you can rest assure it will work for your co-developers as well(unless you consider conflicts).

With that said I'll continue with explaining how to commit.

Committing is done with the CVS command commit. You do this with:

cvs commit

or short

cvs com

another short form

cvs ci

Remember that you can use the global options you learned in part 1, for instance the -z3 might be useful.

When the command is run CVS will start looking trough your directories, starting in the current and recursing trough subdirectories, finding files which are modified locally. When this is done CVS will ask you for a message regarding the changes you have made, this is done with the editor set in the CVSEDITOR variable (this is explained in part 1), when you save this message and quit the editor the changes will be sent to the repository with the change message.
If you want to abort the commit you can do this by quitting the editor without saving.

However committing this way is not what will make you popular with your co-developers, this is because your change message will be appended to all modified files. For instance your bug fix in one of the code files has no use being in the README file. This means that you should commit each file separately (or at least groups of files which belong together). To do this you supply the file(s) after the commit command, for instance:

cvs commit README

which will only commit changes for the README file.

Or using several files

cvs commit qaregexp.cpp qaregexp.hpp

which will commit changes for both the C++ body and header files (C++ body and header files are closely related).

The message itself can also be specified directly to the CVS program by using the -m option. For instance

cvs commit -m "Changed the mail addresses to my new one" README

The last word on committing is that you write sensible messages. Messages saying, fixes, stuff or other meaningless sentences are useless, spend some time writing the messages and make sure you get all changes in it. And remember the spellchecker is not your enemy.

| < 1 > | 2 | 3 | 4 | 5 | Next page >> | Printer-friendly page |

Comment List

Topic:	Author:	Time:
regexps are supported	Marius Sundbakken	26.11.2000 05:23
When commiting changes, it is often necessary to commit both the header file and the source file, and conveniently, cvs support: cvs commit foobar.*
RE: regexps are supported	Jan Ekholm	27.11.2000 10:57
> When commiting changes, it is often necessary to commit both the header file and the source file, and conveniently, cvs support: > > cvs commit foobar.* Isn't this expanded by the shell? CVS just gets the expanded list, such as: cvs commit foobar.h foobar.cpp Or am I out in thw woods here?
RE: RE: regexps are supported	Michael Krumpus	27.11.2000 15:40
> > When commiting changes, it is often necessary to commit both the header file and the source file, and conveniently, cvs support: > > > > cvs commit foobar.* > > Isn't this expanded by the shell? CVS just gets the expanded list, such as: > > cvs commit foobar.h foobar.cpp > > Or am I out in thw woods here? You are correct. The shell handles this, not CVS (or any other program).