Change into the working directory and look around. Entries Repository Root. Now that you have a working directory, you can begin to add files and edit the existing files using your favorite text editor or IDE. Later, once you have completed a batch of changes, you can commit your changes to the repository so they will be available to others. Suppose you want to add driver code to the project in the source file driver. First, create this file and write the code: perhaps a main function, for example.
You might even compile the driver program. While you are editing a working copy, it is a good idea to keep up-to-date with other people's changes to the code.
You can do so with the cvs update subcommand. In addition to retrieving updates from the repository, this command displays a list of the files that differ:. U design. The character in the first column indicates how the file differs from the version in the repository. Files marked with U have been changed in the repository; the working copy is updated to match the version in the repository.
Finally, files marked A there are none in the above example are new to the working copy, but will be added to the repository the next time you commit your changes. The cvs update command downloaded the new version of this file into the working copy; if you were to run update again, design.
In general, it is a good idea to run cvs update frequently, perhaps before editing each file and before committing your changes. This will help ensure that you and your teammates stay in sync and remain aware of each others' changes. Furthermore, it makes it easy to identify and correct conflicting changes early, before they cause too many problems. You should also be aware of the -d command option to cvs update.
This option which must come after the word update tells CVS to also retrieve new subdirectories from the repository into the working copy. By default, only new and changed files in existing directories are updated.
In the previous section you created a new file called driver. To add the file to revision control, use the cvs add subcommand. A driver. As the message suggests, cvs add does not yet add the code to the repository. In general, you should add new source files, documentation, and control files such as Makefile to revision control with cvs add.
However, since executables can easily be rebuilt by running make , there is usually little reason to add them to the repository. As you saw earlier, cvs update can be used to show the list of files that you have modified in the working copy.
Sometimes it is useful to have more detailed information about exactly what has changed. You can use the cvs diff subcommand to get a line-by-line list of all changes between your files and the versions they are based on.
The list of changes can be viewed on-screen or redirected to a file; the output is in diff format , and can therefore be used with the patch utility. There are also additional command-line options to compare different versions of the project, instead of just the working copy; see the CVS documentation for more information.
When you run cvs update , you may find that someone else has been working on the very same files as you. For example, while you added driver. When you perform the update, CVS will try to automatically merge your changes with the updates from the repository:.
Merging differences between 1. Sometimes, however, CVS is not able to merge the changes. This typically happens when you and another developer have both changed the very same lines of code. In this case, CVS will report a conflict and require you to manually fix the problem. In cvs update , files with a conflict are marked with the letter C. You cannot commit your code until you fix the conflict somehow. Try to save our changes to the repository. It looks like we'll have to actually fix the conflict.
When a conflict occurs, CVS inserts special markers into your file which show both versions of the code. To fix the conflict, you must figure out how to combine the changes to get the effects of both; this sometimes will require the help of the other developer.
Edit the file to manually merge the differences and remove the markers, then commit the changes. More information, with a detailed example, is available in section After some amount of editing and updating, you will be ready to check your modified code into the repository. This is accomplished with the cvs commit command sometimes abbreviated cvs ci , for "check in". If there are any out-of-date files in your working copy, cvs commit will give an error message "Up-to-date check failed" and refuse to check in your changes.
If this happens, simply run cvs update and commit again. Someone has made another change, need to update. Now we can commit. When you are finished, save.
Checking in driver. When you commit your code, CVS launches a text editor for you to add a log message. This message will become part of the version history of the changed files, allowing your teammates to understand how your code has evolved. In your log message, you should describe the content and purpose of the changes you have made to the code. If you have trouble remembering what changes you made, refresh your memory with cvs diff. Commit the specified files or directories to the repository.
If you do not specify any filenames, commits the entire working directory to the repository. Use message as the log message instead of launching an editor. Use the contents of logfile as the log message instead of launching an editor. Operate only on the specified files or the current directory, but not on any subdirectories.
Your log mesages should be clear, descriptive, and easy to understand. The log messages should list the changes, additions, and deletions you made, including the names of affected classes, methods, and functions. Even more important, you should list the reason for each change. Related changes should be grouped together.
Some people prefer to list the changes in the present tense "Add new class Instead of modifying your programs in huge batches of changes, it is usually a good idea to make a series of small, incremental changes. This imperative conflicts somewhat with 2. If your team or even one member makes a habit of committing broken code, you will quickly learn that it is dangerous to run cvs update it might break your code! Of course, it is impossible to avoid bugs altogether, but you can take steps to make sure your changes don't stop work for everyone else.
At a bare minimum, make sure your code compiles before checking it in. You will find that making small, incremental changes 2. Beyond just compiling your program, you should test it to make sure it doesn't contain any regressions : detrimental changes in behavior from the previous version. Automated unit testing is very helpful here, because then a simple " make test " will perform a number of tests to tell you whether the code still works.
Of course, your team has to write the tests! Of course, the log messages collected by CVS would be useless if there were no way to view them. CVS provides the cvs log subcommand to view the history of a file, including log messages. If you do not specify a filename, the command shows the history of all files including those that have not changed.
This first version. Initial revision. Initial import. Sometimes it is helpful to get more precise information about the version history of the source code. For example, it is often useful to know who wrote or last modified a particular line of code, or what other code changed at the same time. CVS provides the cvs annotate subcommand for this purpose: it displays a file or files with annotations indicating the revision, date, and committer of the last change of each line.
As with cvs log , this subcommand can be given a filename, or used alone to display annotations for every file in the project.
You have seen how to use CVS to keep a team of developers in sync and make sure everyone is working with the latest code. Sometimes, however, it is necessary to work with different versions of the code. For example, if you discover a bug, you might want to look at, or even compile and run, older versions of the code to determine whether the bug was already around back then, or whether it is new.
In CVS, each file in the repository has a number of revisions. Each revision is a dotted sequence of numbers, such as 1. A revision such as the latter with more than two components is part of a branch.
Each time you modify and commit a file, the last component of the file's revision increases by one. For example, 1. If you commit an entire directory, only those files that have changed will get new revisions. Thus the files in a project will often have different revision numbers.
The cvs log subcommand can be used to list the revisions of a file. Many CVS subcommands allow you to work with versions other than the most recent. Among the subcommands you have seen, checkout , update , and diff all allow you to work with versions other than the latest.
The following are command options, and thus must follow the subcommand name. Use the specified revision instead of the latest. The revision may be either a number most useful when dealing with a single file or a symbolic tag.
Use the revision as of the specified date. This option selects the last revision that was made on or before the given date.
There are a number of date formats allowed; if the date contains a space, you must surround it with quotes. February 11, September 12 of this year. What it sounds like.
It can be difficult to remember the revision numbers for particular versions of your source code. This is especially true when there are multiple source files, each with a different revision number. You can avoid this difficulty by creating a symbolic tag. A tag is a name which refers to a particular version of some set of files perhaps a single file, or the whole repository, or anything in between.
To create a tag, use the cvs tag subcommand:. Add the current versions of the specified files to the symbolic tag tagname. If no files are specified, add the current versions of all files to the tag this is the usual usage. For the purpose of adding tags, the "current version" of a file is the revision that is currently checked out, ignoring uncommitted changes.
Make the tag a branch , allowing new versions to be derived from the tag without affecting mainline development. Delete the specified tag. If the tag already exists for a file, move the tag to the current version. If you are new to CVS, it's recommended that you begin in the first section and proceed to the second section; if you have some basic CVS experience but are going to be using CVS as a full-fledged developer for the first time, you should find everything you need in the second section, but you may want to go through the first section as a review.
Using the cvs client tools, developers can make changes to the contents of the repository. In turn, the cvs repository tracks every change made to every file, creating a complete history of the evolution of the development project. Developers can request older versions of a particular source file, view a log of changes, and perform other useful tasks as needed. A lot of open software projects have their own CVS servers, which are used by the project developers as a central repository for all their work.
Developers often make improvements to the sources in the CVS repository on a daily basis; and often, these developers are scattered around the world, yet CVS provides the necessary mechanism to unite their project into a centralized, cohesive whole. CVS creates the "organizational glue" that allows these developers to make improvements to the code without stepping on each other's toes, losing important data or missing each other's critical updates to particular source files.
When the developers are ready, they'll roll some their current work on CVS into a. However, the latest official release sometimes isn't recent enough, for a variety of possible reasons.
In the first section of this tutorial, I'll show you how to use CVS for this purpose -- acquiring the latest and greatest developer version of the sources for your own personal use.
To install cvs, just type in emerge cvs :. Before we begin, there are a few CVS fundamentals that you need to know. The leading ":pserver:" part tells our client to connect to this remote machine using the CVS password server protocol, a protocol that's built-in to CVS. Typically, public CVS repositories use the password server protocol to allow access to anonymous users.
The ssh access method is popular with those who are concerned about security; however, neither the RSH or SSH method provides a way for anonymous users to get the sources. In order to use this method, you must have a login account at foo. In addition to the CVSROOT, you'll also need to know the name of the module collection of sources that you'd like to check out, as well as an anonymous password that you'll need to log in to the CVS password server.
Unlike anonymous ftp, there is no "standard" format for the anonymous password, so you'll need to get the specific password from the developer web site or the developers themselves.
Once you have all this info, you're ready to begin. Grabbing the sources is a two-stage process. First, we log in to the password server. Then, we grab the sources with a checkout command. If you don't set this variable, the following two commands will require an additional -d :pserver:cvs pserver.
Here are the commands needed to get a current copy of the developer sources. You may want to jump forward to the next panel to read the explanation of these commands, and then jump back here.
The first cvs command above logs us in to the pserver, and the second tells our CVS client to check out "co" the samba module using a gzip compression level of 5 "-z5" to speed up the transfer over a slow link. For every new file that is created locally, cvs prints out a "U [path]" indicating that this particular file has been updated on disk.
Once the checkout command completes, you'll see a "samba" directory in your current working directory that contains the latest sources.
You'll also notice that all the directories have a "CVS" directory inside them -- CVS stores accounting information inside these directories, and they can safely be ignored.
From this point forward, we don't need to worry about having the CVSROOT environment variable set nor do we need to specify it on the command line because it's now cached inside all those extra "CVS" directories.
Well, there you are -- fresh sources! Now that you have the sources, you can go ahead and compile and install them, inspect them, or do whatever you like with them. Every now and then, you may want to bring your checked-out source directory in-sync with the current version on CVS.
To do this, you don't need to log in to the pserver again; your authentication info is also cached by cvs inside those "CVS" accounting directories. First, enter the main checked-out directory in this case "samba" , and type:. If there are any new files, cvs will output "U [path]" lines for each one as it updates them. Also, if you compiled the sources, you will probably see a lot of "?
Also, notice the two command-line options we used for "cvs update". When it comes to simply grabbing the latest sources, that's about all you need to know. Now, we take a look at how to interact with CVS as a developer. As a developer, you'll need to modify files on CVS. To do this, simply make the appropriate changes to your local copy of the repository. The changes you make to the sources are not applied to the remote repository until you explictly tell cvs to "commit" your changes.
When you've tested all your modifications to ensure that they work properly and you're ready to apply your changes to the repository, follow this two-step process. Adding files First copy the. Now, for any files that you want CVS to control, register them in the repository: cvs add sample. Go ahead and commit them: cvs commit -m "original file" sample. This latter form is usually more useful.
Write good log messages! It updates your working directory from the repository, but also tells you status of files. Try it: cvs update Probably all you got was a message like "cvs update: Updating. The result of update will have the letter M next to the sample. This indicates that you have modified the file.
Other letters you sometimes get are P, which means CVS has patched the file from other updates in the repository, or U, which means CVS has copied a new file that wasn't yet in the working directory.
0コメント