Skip to content
Gijs Molenaar edited this page Feb 13, 2014 · 4 revisions

Various tips & tricks

One thing to keep in mind when reading these examples: if no filenames or directory names aregiven to a cvs command, it applies recursively starting at the current directory. For directory names, it applies recursively starting at the specified directory. For filenames, it applies to the given file only.

Consequently, any cvs command without arguments executed in LOFAR/Timba applies to the entire source tree.

Reverting to an earlier version

$ cvs up -D 06may

Note that this sets a **sticky tag** on files and directories from the current directory down. This means that further updates using just `cvs up` do not actually update, but keep the _sticky_ version, in this case May 6. 


### Removing a sticky tag

* ```
 $ cvs up -A

This guarantees the latest revision.

Working with experimental branches

(NB: some of this is quoted straight from the cvs man page)

Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like:

hacked sources are present $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit

(_EXPR1_ is of course the branch name, whatever you happen to choose). The update command will make the `-r EXPR1` option sticky on all files.  Note that your changes to the files will never be removed by the update command.  The commit will automatically commit to the correct branch, because the -r is sticky.  You could also do like this: 

* ```
 [[ hacked sources are present ]]
 $ cvs tag -b EXPR1
 $ cvs commit -r EXPR1

but then, only those files that were changed by you will have the -r EXPR1 sticky flag. If you hack away, and commit without specifying the -r EXPR1 flag, some files may accidentally end up on the main trunk.

To switch their local copies to the experinental branch, other developers would do:

at whatever directory, or at the LOFAR/Timba level $ cvs up -r EXPR1

Later, once everything works, you want to merge the experimental branch back into the main trunk. Do it as follows. First, commit all changes to the branch: 

* ```
 $ cvs commit

This commits changes to the branch (since you presumably still have the sticky tag set.) All your branch changes are now safely stored in the repository. Get your local copy in sync with the main trunk again:

$ cvs up -A

This clears the sticky tag, you're now sitting on the main trunk again. Now, merge the branch changes **into** your local sources: 

* ```
 $ cvs up -jEXPR1

...and check cvs output for any possible conflicts. Assuming everything still compiles and works right, commit the merged version to the trunk:

$ cvs commit

Clone this wiki locally