Files
oldlinux-files/docs/kgb/cvs_client_info.txt
2024-02-19 00:23:35 -05:00

185 lines
4.1 KiB
Plaintext

=====================
Basic CVS Client Info
=====================
Client usage
"client" basically means the `cvs` command or some wrapper
for it.
Basic concepts
Anything located in a subdirectory of a CVSROOT is considered
a cvs module. In our server example, the "shell_scripts" is a module.
cvs commands tend to deal with either a module at a time, or individual
files.
Setting up a CVSROOT
examples:
export CVSROOT=/usr/local/cvsroot
export CVSROOT=:ext:foo@somehost.com:/usr/local/cvsroot
export CVSROOT=:pserver:bar@somewhere.net:/usr/local/cvsroot
Logging into cvs
cvs login
then the appropriate passwd. This is really only needed for
pserver methods.
Checking out a module
cvs checkout module_name
example:
for checking gimp out of gnome from scratch:
export CVSROOT=:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome
cvs login
(hit return, there is no passwd)
cvs -z3 checkout gimp
(wait....)
Thats it.
The -z3 is a cvs option telling it to use compression level 3
for files it transfers.
Updating a module
We'll assume were using pserver type configuration from here
on out.
cd dir/
cvs -z3 update -Pd
(the -Pd isnt absoultly necessary, but what the heck).
Adding a file to the cvs repo
(create the new file)
cvs add new_file
cvs commit
This will add the new file to the repo.
Committing changes
(change something with the files)
cvs -z3 commit
(this will pop up a text editor. What this is for is
for you to enter in some sort of meaningful messages about
what changes you made)
Then it will commit those files to cvs.
If you get "uptodate" errors here, you will need to update
your local tree first. See the section on updating.
Merge conflicts
Occasionally, if patch can figure how to handle the diffs between
what you have locally, and whats in the repo, you will get merge
conflicts when you update.
If you need to merge these by hand, the conflicts get marked in
the file with
>>>>>>>>>>>>>>>
Your stuff
==============
The stuff from the rep
<<<<<<<<<<<<<<<<<<<<<
So you will need to figure out which one is correct, and
then clean up all the ">>>>" and "======="'s
Or if you don't care about the conflicts, rm the file and update
again.
Removing a file from the repo
rm file_name
cvs remove file_name
cvs commit
Note that you have to remove the file locally first, then
`cvs remove` it.
Diffing what you have with the repo
Very often you will need to get a diff between what you
have locally, and what is in the tree. You might need to
do this to send a patch, or just to see what all you
have changed.
cvs diff -u
(for the whole module)
cvs diff -u filename
(for a specific file)
the -u just tells it to used "unified" diff format, which
tends to be a little easier to read.
Thats about 99% of the commands you need to know to use cvs
on a day to day basis. For keeping up with most projects
that are cvs based, just login, checkout, and update are
all you need. add, remove, diff, commit are about it
for using a cvs tree. Of course, there are lots of
other tricks involved.
Different "Branches" and trees
Cvs has the ability to maintain different
"branches" or forks or a code base, and keep them in
the same cvs server. This is primarily used when
someone is doing something that might break a program
or otherwise would be best left out of the main or
HEAD branch for a while.
To check out a non-HEAD (HEAD is the primary branch),
you use the -r command line option to checkout,update, etc.
to check out the HOLLYWOOD version of gimp
cvs -z3 co -r HOLLYWOOD gimp
Once its checked out, it knows its HOLLYWOOD branch,
so you don't need to use the -r option. However, if you wanted
to go back to the main HEAD branch, you would have to
specify that.
Reverting or checking older versions
One of the primary advantages of revision control is
the ability to go back to older revisions of modules or
trees.
For example, if for some reason, you needed to get
a version of a file from , 1, 1999.
cvs -z3 update -D "Nov 1 1999"
The date string is pretty flexible.