These are not available in CVS 1. They are:. Process the file through the filter program every time the file leaves the repository. Process the file through the filter program every time the file enters the repository. The modules file contains information about projects in the repository and can group arbitrary files or directories into a single module.
Information in this file must be created by the repository or project administrator; CVS does not update this file when a new project is imported. Once a module is defined, the project files and directories it defines can be checked out into a sandbox using either the module name or the name of the repository directory it represents. A module can represent a directory and all its files and subdirectories, a file, or any collection of such files or directories.
Directories can also be excluded from a module explicitly. Module definitions are useful for splitting a project into several virtual projects, especially when you need to have several projects that share common files.
You can also use module definitions to merge projects into a single virtual project. If you intend to use modules for project organization, be aware that modules are not versioned. If you change the structure of the project, you may not be able to retrieve old releases with the module names in effect at the time those releases were current. For example, if you create an animal project with elephant and turtle subprojects, then later change the name of turtle to tortoise , there is no way to record that versions of the project prior to the change use turtle and versions after the change use tortoise.
The modules file can also specify programs to run when files in the module are committed, exported, updated, checked out, or tagged with rtag. These programs can be used to integrate CVS with bug trackers or other project-management or program-development tools. The developers of CVS recommend that you use the scripting files rather than the options in the modules file. Use the files described in Section 6. Chapter 7 explains the modules file in detail. The notify file contains the commands to run when conditions exist for cvs watch to notify a user of a change to a watched file.
Chapter 5 explains uses for the notify file and provides an example in Example The syntax of the notify file is a series of lines, each line appearing as follows:. The filename pattern can be ALL or it can be any CVS standard pattern, as used in cvsignore and cvswrappers and explained in Chapter The rest of the notification information is provided to the command through standard input -- stdin , in Unix or Linux.
CVS does not notify you of your own changes to a file. The files described in this section control scripts that run at specific times when the repository is modified. They can be used to interface CVS to bug-management or change-tracking systems, integrated development environments, or other tools; to enforce compliance with a project policy; or to trigger processes such as automated export programs to keep an up-to-date copy of the project files on a file server.
These files usually are configured on a per-project basis, so Chapter 7 explains them in more detail. For most of the files, the syntax is a series of lines, each containing information in the following pattern:.
The name pattern defines which files the action is run for and may include the project's root directory. The action is used to specify programs, and the programs defined in these files are passed the results or parameters of CVS commands, either as parameters or via standard input. The commitinfo file defines programs to run before a file is committed.
Typical uses include determining whether a file meets your project's coding standards or whether a system configuration file has the correct syntax. If any of the programs exit with a nonzero exit status, the commit will not proceed. The editinfo file is obsolete and has been replaced effectively by verifymsg and rcsinfo. In CVS versions that use editinfo , it enforces the use of a specific editor when entering log messages.
If CVS is called from a remote client or if the -m or -F command options are used with cvs commit , the editinfo file is not used.
If the editor exits with a nonzero exit status, the commit will not proceed. The loginfo file defines programs to run when a file has been committed successfully.
The loginfo file is intended as a way to record log messages to specific places, such as a ChangeLog generation program, but is often used to trigger automated export programs. The rcsinfo file does not actually trigger any scripts, but it uses the same syntax as the scripting files. It defines forms to be displayed as the template for commit log messages.
The taginfo file defines programs to run before a file is tagged. Typical uses include determining whether tag names meet your project's standards, and logging tags. If any of the the programs exit with a nonzero exit status, the tag will not proceed.
The verifymsg file defines programs to run after a log message for a commit has been entered but before the commit takes place. The programs are passed the log message and can modify it or parse it to ensure that all essential fields have been filled in.
The verifymsg file usually is used in tandem with the rcsinfo file to manage log messages and sometimes to interact with bug-tracking programs. If any of the programs exit with a nonzero error status, the commit is aborted. The files in this section contain information CVS refers to when processing commands.
You can set the information for most of these files, but history and val-tags should be written to only by CVS. The checkoutlist file contains a list of user-defined files stored in the CVSROOT directory and exported into that directory when they're committed, in the same way that the standard administrative files are.
This can be a useful way to store user-defined scripts for the other administrative files. Here is the first hunk:. The pair of numbers in each indicates the range of lines shown. Thus, one can see that the single line in the top half was replaced with the two lines in the bottom half.
CVS omits the old text in this case, because it would be redundant. CVS uses a similar hunk format to describe deletions. Like the Unix diff command, output from cvs diff is usually called a patch , because developers have traditionally used the format to distribute bug fixes or small new features. While reasonably readable to humans, a patch contains enough information for a program to apply the changes it describes to an unmodified text file.
In fact, the Unix patch command does exactly this, given a patch as input. CVS treats file creation and deletion like other changes, recording such events in the files' histories. One way to look at this is to say that CVS records the history of directories as well as the files they contain. CVS doesn't assume that newly created files should be placed under its control; this would do the wrong thing in many circumstances. For example, one needn't record changes to object files and executables, since their contents can always be recreated from the source files one hopes.
To add a file to a project, you must first create the file, and then use the cvs add command to mark it for addition. Then, the next call to cvs commit will add the file to the repository. CVS prompts you for a log entry If you delete a file and then run cvs update , CVS doesn't assume you intend the file for deletion.
This means that if you want to undo the changes you've made to a file in your working directory, you can simply delete the files, and then let cvs update recreate them. To remove a file from a project, you must first delete the file, and then use the cvs rm command to mark it for deletion.
Then, the next call to cvs commit will delete the file from the repository. Committing a file marked with cvs rm does not destroy the file's history. It simply adds a new revision, which is marked as "non-existent. There are several strategies for renaming files; the simplest is to simply rename the file in your working directory, and run cvs rm on the old name, and cvs add on the new name. The disadvantage of this approach is that the log entries for the old file's content do not carry over to the new file.
Other strategies avoid this quirk, but have other, stranger problems. If one can use cvs diff to retrieve the actual text of a change, why should one bother writing a log entry? Obviously, log entries can be shorter than a patch, and allow the reader to get a general understanding of the change without delving into its details.
However, a good log entry describes the reason the developer made the change. For example, a bad log entry for revision 1. Then create a subfolder for this project. You may even want to create separate subfolders for each module if you're working in more than one. Click on the left window in the program and select a folder. Then select Cvs Admin - Checkout Module.
Select the project folder you created earlier. Enter project module name and click OK. You should see a scrolling list of filenames as these are created in your folder s. Repeat the module creation process for each additional cvs module you wish to check out. Top Help index.
0コメント