.TH CVSQ 1 "Feb 9, 2008" "" "" .SH NAME cvsq - queue cvs (and others) commands to be executed later .SH SYNOPSIS \fBcvsq \fR .br \fBcvsq add file1 file2 ...\fR .br \fBcvsq dir directory\fR .br \fBcvsq up\fR .br \fBcvsq desc\fR .br \fBcvsq queue\fR .br \fBcvsq diff [file]\fR .br \fBcvsq do\fR .br \fBcvsq ambient ...\fR .br \fBcvsq ambientpost ...\fR .br .SH DESCRIPTION Schedule cvs commands to be executed later. As opposed to earlier cvs queueing scripts, this version of cvsq (and all later versions) allows to schedule several commits for the same file. Also, when scheduling a commit, a safe copy of the directory is kept. In this way you can continue editing, without worrying about destroying the scheduled commit. Scheduling commands instead of executing them immediately is useful on machines (such as laptops) that cannot access a cvs repository at any time. See lcvs(1) on how to mirror a cvs repository for reading. \fBcvsq\fR .br \fBcvsq ci\fR .br The default action. Schedule a local commit for the current directory. It must be a cvs working directory. Note that scheduling the commit does not guarantee that the commit will eventually end up in the repository. It still is the user's responsibility to ensure that no conflicts arise when a commit to the repository is to be carried out; here, the actual commit will be carried out at the time of upload. Currently, cvsq does not provide any help in resolving conflicts with locally scheduled commits; however, the file structure in the queue is simple enough that manual resolving usually is easy enough. See cvsq-files(5) for details. Nevertheless, it's better to avoid conflicts in the first place. An alternative to resolving the conflict immediately is to first commit to a branch and merge in the changes later. This will also allow to empty the queue immediately and is therefore preferable. A simple call to cvsq-branch(1), followed by another call to "cvsq up" will have this effect in case of a commit failing due to a conflict. cvsq-merge(1) gives some help for merging in the branch later (not necessarily in the same working directory). \fBcvsq add file1 file2 ...\fR .br Schedule the addition of the mentioned files. Do not use this command for directories. Use cvsq dir instead. \fBcvsq dir name\fR .br schedule the directory name for addition to cvs. This will also generate an empty directory name/CVS in the working directory, so that scheduling commits later will handle this directory correctly. Of course, at the time of upload, this will be replaced by the administrative directory generated by cvs(1). \fBcvsq up\fR .br \fBcvsq upload\fR .br Upload all the scheduled commands to the repository. This requires the repository to be accessible. \fBcvsq desc\fR .br List the human readable descriptions (where provided) of the scheduled commands. The output is easy to understand for a human; however, programs should make no assumptions about any particular shape of the output. \fBcvsq queue\fR .br List all working directories in which commits are scheduled. The directories are mentioned in lines of the form optional whitespace, followed by a non-empty sequence of digits naming the slot, followed by a non-empty sequence of whitespace, followed by the directory name, followed by a newline character. The output may contain other (explanatory) lines, however none of them of the shape that the first block of non-whitespace characters consists of digits only. The data is taken from the "dirnames" subdirectory; see cvsq-files(5) for details. \fBcvsq diff [file]\fR .br Compare the specified file (or ".", if no file is given) with the latest copy of this file in a directory scheduled for commit. The comparison is done using diff(1) and the option "-r" is given. \fBcvsq do\fR .br \fBcvsq pre\fR .br \fBcvsq immediate ...\fR .br Call "cvs ...". This could be useful, if you have specified some prefixes (hence the synonym "pre" for this command), in ~/.cvsq/config/prefix. See cvsq-files(5) for the precise syntax of the configuration files. See fsh(1) to find out why you want to use such a prefix. \fBcvsq ambient ...\fR .br Schedule "ambient" commands, i.e., commands not necessarily related to version control at all, to be executed at the time of upload. The remaining arguments are considered as command that will be executed in the current directory at the next "cvsq up". Note, however, that the environment is not stored; instead it will be that of the call to "cvsq up". \fBcvsq ambientpost ...\fR .br The same as "cvsq ambient", but the commands are scheduled in the post queue. See cvsq-files(5) for details of the queues. Note that in the post queue no repositories may be accessed; however are purely passive observation as that of an lcvs(1) synchronisation is alright. In fact, the very reason for introducing ambientpost was to avoid forgetting to synchronise at upload local mirrors of repositories one is currently busy scheduling commits. .SH INTERNAL COMMANDS The following ways of calling \fbcvsq\fR, though specified, are most probably not useful for interactive use. \fBCVSQ_ACTION=hardlink cvsq hardlink source target slot\fR .br Recursively compare all files in the source directory to those in the target directory. This call will create a file (in the current directory) named slot-late-hardlink that, when executed by sh(1) will replace every file in the source directory that had identical contents with the corresponding file (i.e., same name) in the target directory by a copy of the corresponding file in the target directory. Here "identical contents" is determined by cmp(1) and refers to the time when cvsq was called (not the time the generated file is called!). To avoid accidental use of this function, it is required that the environment variable CVSQ_ACTION be set to the value "hardlink". Also, if CVSQ_ACTION is set this way, it is expected that the first argument to cvsq be "hardlink". Otherwise cvsq will abort. \fBRemark:\fR the name "hardlink" is for historical reason. Originally, the command replaced the files by hardlinks at the time of calling. This had the effect, that changes a "cvs ci" did to the file (expanding Id tags, and similar) were correctly propagated to next commits. However, this had the disadvantage, that the working directory had to reside on the same partition as the home directory. To overcome this problem, files are now actually copied, after the changes due to "cvs ci" have happened. Comparison of files still is in the pre-commit phase. .SH ENVIRONMENT VARIABLES \fBCVSQ_MAKE_CLEAN\fR .br The command to be run in the local copy of the working directory that is saved when a commit is scheduled. A typical value would we "make clean" to save a bit of space in the queue. This can be overridden by giving the -clean= option. If the option -noclean or -nc is given, no cleanup command will be run. \fBCVSQEDITOR\fR .br \fBCVSEDITOR\fR .br \fBVISUAL\fR .br \fBEDITOR\fR .br The environment variables used (in that order) to determine which editor is to be used to edit the log message. If none of these variables is set, /bin/ed is used as a default. .SH OPTIONS \fB-svn\fR .br Queue commands to a svn(1) repository instead of a cvs repository. That is, assume that cvs is called "svn" and that the directory with administrative information is called ".svn" instead of "CVS". \fB-force\fR .br Normally refuses any actions calling cvs or modifying the queue if no subdirectory named CVS is found in the current subdirectory (if the option -svn is given, then for the existence of a subdirectory named .svn is checked instead). The option -force tells cvsq not to carry out this check. Note that this will result in a command being scheduled that is doomed to failure (or in case of "cvsq do" a command carried out that will fail immediately). So don't use this option unless you have a very good reason to do so. You have been warned! .SH FILES \fB~/.cvsq/ \fR .br The directory that cvsq stores the queue of the commands to be executed. See cvsq-files(5) for a description of the file structure and how to schedule commands other than by calling cvsq. .SH WARNING cvsq uses the administrative information in the CVS subdirectories directly instead of copying them. This allows to correctly handle several successive commits to the same file. It also has the effect the administrative information in your working directory will be up to date after an upload. However, it also means, that you must not modify the administrative information in the CVS subdirectories (either directly or by calling cvs(1) or lcvs(1)), once you have a scheduled commit. It also means that you have to keep your working directory till after the upload (even though otherwise you wouldn't lose any files, but you would lose the information, where these files are to be committed to). .SH SEE ALSO .BR cvq-files "(5), "cvs "(1), "lcvs "(1), "fsh "(1), "cvsq-branch "(1)" .SH AUTHOR Klaus Aehlig . Part of this script was inspired by an earlier script of Vaclav Slavik.