setenv CVSROOT :pserver:$USER@cvs.astro.umd.edu:/home/cvsroot
cvs updateand works heirarchically down through all your CVS enables directories. No more trying to find out which of your personal copies has the most recent file....
setenv CVSROOT /home/mycvsroot
cvs -d $CVSROOT init
Using this repository is now the same (with the beforementioned $CVSROOT):
cd /home/mycode/myproject
make clean
cvs import -d -m "testing 1 2 3" myproject vendor start
cd ..
mv myproject myproject.old
cvs checkout myproject
setenv CVSROOT :pserver:$USER@cvs.astro.umd.edu:/home/cvsroot setenv CVSEDITOR emacs # or whichever editor you preferAnd you will also have to negotiate a password with the CVS maintainer (currently: teuben@astro.umd.edu) and tell him your $USER name of course. You can also download this perl script, which produces the encrypted passwd that you can safely send via email, or use the output of the following :
perl -e 'print crypt("my_password","b6"), "\n";'
and you better not send me back the string "b60j72OwWnjlk" :-)
PLEASE NOTE THAT MacOSX USERS APPEAR TO HAVE TO USE TO USE A LOWER CASE PASSWORD
cvschroot allows you to edit your CVS/Root entries recursively. (you also need cvsu). You can probably find that under the "cvsutils" package on most linux distributions.
The very first time before you use this so-called "pserver" CVS access method, you need to logon:
cvs loginThis will maintain your password, encrypted, in a file in ~/.cvspass, so you will never get asked again. Sort of like the .ssh/authorized_keys file for automatic authenticated ssh usage.. Btw, you never have to do a logout from cvs (although the command does exist), unless you are worried somebody might steal your encrypted password. Hint: if you ever forget your password for a new machine, just copy the appropriate line from your ~/.cvspass file to that new machine.
If you want to start a new module in the CVS server, the following chain of commands gives an example of that:
cd /home/user/myproject ## this directory tree will be imported into CVS
make clean ## or manually clean anything in this tree that should not be part of the CVS archive
cvs import -d -m "some comment ...." myproject vendor start ## (see comment below)
cd ..
mv myproject myproject.old ## myproject.old can be removed even
cvs checkout myproject ## get a new sandbox
cd myproject ## now you are ready to edit/commit/update etc.etc.
Note that the "vendor start" is the CVS suggested method. The new module name, myproject, is preserved
in this case, but you are free to choose any module name at that stage.
For existing modules, the first time you want to "checkout" the whole CVS miriad tree, do
cd /opt ## or whereever you want to "root" miriad cvs checkout miriad ## would create /opt/miriad and all belownow install miriad in fashion you normally do, from within /opt/miriad. You may notice a lot of CVS directories. Don't ever touch them, CVS uses them for administrative maintenance :-)
cd miriad # go to the root of your project cat CVS/Root # should be old value cvschroot $CVSROOT # recursively change the whole tree cat CVS/Root # now notice new valueand it will do them all hierarchically. You can download the two perl needed scripts here: cvschroot and cvsu. They are part of the cvsutils tools. Don't forget to make them executable (chmod +x)
:pserver:ptueben@cvs.astro.umd.edu:/home/cvsroot xA_20?(3(do not touch the garbage at the end, it is an encrypted form of your cvs password), or, alternatively, you can also re-enter your password for the new $CVSROOT by issuing
cvs login
cd $MIR/src/prog/analysis cvs commit moment.forAs with all commit's, CVS will then throw you into an editor and urge you to add a line to describe why/what you have done. This information will go in the logfile, which is kept on a per-file basis (see the "cvs log" command).
cd $MIR cvs -n -q updateand it will report a number of files, preceded with a single character code on their status:
? doesn't know the file in the archive, so will skip it
U file is newer in CVS, so you need to "update" it
P the same as P, except CVS would decide to path the file
instead of updating the whole file. Great for slow links.
M file is newer in your version, so you need to "commit" it
C there is a conflict :-) You first need to "update" it,
or "diff" it first, then study the resulting merge, and
then "commit" it back to the archive.
So, to sync your tree back with CVS, do:
cvs updateor
cvs update -d -Pif you want to be sure new directories are added (not done by default...) and empty directories are pruned.... This will report about all the patching going on to sync your tree. Note it will not mess with your modified (M) files, it will leave them alone. It's up to you to "commit" them when you're ready for that. For the conflict (C) cases, special care is needed of course, and I will write about that more later.
cd $MIR/src/prog/analysis cvs add newmoment.for <-- tag it to be added cvs commit newmoment.for <-- add the file physically to CVS now cvs add -kb picture.gif <-- tag it to be added, and as binary file or for an already existing file to change it to binary cvs admin -kb picture.gif cvs update -A picture.gif <-- but there is danger of bad cr/lf conversion(note that binary files should add the -kb flag, to avoid interpreting some magic markers and cr/lf issues), for directories you can skip the commit step:
cd $MIR/src/prog/ mkdir atnf cvs add atnf
cvs edit moment.for
....
cvs commit moment.for
If you want to abandon you changes, simply do
cvs unedit moment.for
An even more advanced method is to set a watch on the file. See the CVS
manuals for more details.
rm badmoment.for
cvs remove badmoment.for
cvs commit badmoment.for
cvs diff moment.for <-- your local with your last checkout
cvs diff -Dnow moment.for <-- your local with last CVS archive
cvs log moment.for <-- revision history of this file
cvs diff -r1.2 moment.for <-- your local with archive version 1.2
By far the tkdiff (see also
tkdiff home page)
utility is more useful. It also knows
about CVS, and the default usage
tkdiff moment.for
tkdiff -r1.12 moment.for
does the right thing, and present two colorful screen, side-by-side, of the CVS HEAD version
with your local version. You can also use the usual -r1.2 flags to difference with an
older CVS revision id. The following exceedingly simple shell script is
actually quite useful to keep track of daily updates in a CVS tree:
#! /bin/csh -f
#
foreach file (`cvs -n -q update | grep ^U | awk '{print $2}'`)
cvs log $file
tkdiff $file
end
mv old.for new.for
cvs remove old.for
cvs commit -m "renamed old.for to new.for" old.for
cvs add new.for
cvs commit -m "renamed old.for to new.for" new.for
cvs admin -kb badfile
cvs update -A badfile
For non-Unix system one would actually still have to check-in (commit)
a correct brand-new version of the data, because of the CR/LF
translations.
cvs add miriad_cube
cvs add -kb miriad_cube/*
cvs commit miriad_cube
cvs -d :pserver:anonymous@cvs.red-bean.com:/usr/local/cvs login cvs -d :pserver:anonymous@cvs.red-bean.com:/usr/local/cvs co cvsutilsand read their documentation. In particular the before-mentioned cvsu and cvschroot commands are useful.
cvs update -p -r 1.1 file1 > file1
will get a local copy, you
can edit that file and commit it again. You can probably also
retrieve by date, if you prefer that, e.g.
cvs update -p -D "25 August" file1 > file1
The problem is that all 1.1 -> 1.2 revisions are now lost in version 1.3
If however, you don't use the -p flag, a sticky flag will be set
cvs update -r 1.1 file1
and when you want to commit any edited revisions, you first need to
remove the sticky flag with
cvs update -A file1
this will attempt to merge your local revisions with the CVS head, 1.2 in
our example, and when you commit this it will become 1.3. This will thus
include the 1.1 -> 1.2 revisions.
:pserver:user_name@cvs.astro.umd.edu:/home/cvsroot Axy66s:q
where the last characters on the line is your encrypted password. If this looks
right, you may have messed up someting else, so we need to make a new
password. You then need to
download the show_passwd.pl perl script,
and make a new hash of the enrypted passwd, e.g.
perl show_passwd.pl my_secret_password
Hbgvfcr9kJP6Q
email me the encrypted one, and i will fix this. Alternatively, if
you have another account with the correct .cvspass file, go there
and copy that line into the one on your current machine. If that
also fails, and I happen to be at 35,000ft, and you really need
access to the code, use the anonymous account (it has
no password, but is only read-only). You may also need
to change the username on an existing sandbox, as described
earlier using the cvsu utility.
cvs update -A
and it should fix that.
cvs update -d
you can also add, it forces checking new directories. It is normally not
done, presumably for efficiency reasons.
update -d -P
to your ~/.cvsrc file.
cvs update file merge in the modified file
tkdiff file <-- in particular notice any <<< and >>> symbols
emacs file
cvs commit file
If that fails, or you don't care about your modifications and will
do them later another way, remove yours (or the badly merged one)
and checkin a new one:
rm file
cvs update file
cvs tag -b TAG1 # create a branch (from the top, or use rtag)
cvs update -r TAG1 # switch your sandbox to the new branch
cvs checkout -r TAG1 -d proj_TAG1 proj # or checkout a new branched version
cvs update -j TAG1 # merge a branch to mainline
cvs commit # commit them back to mainline
Although branching is very powerful, it is a somewhat more advanced
usage of CVS. See also
CVSLines, with
a wizard program to manage branching.
Another hairy issue with Windows (since Mac's now follow the unix convention) is the CR-LF nature of the end-of-line marker for text files. Although CVS deals with this transparantly, sharing files via SAMBA is now a no-no, and postscript files (which are supposed to be ascii) with embedded binary sections (legal in level 2 Postscript) can also be a big nuisance.
cvs up -dPC
but if you want to create a patch file, that you can pass on to another
CVS repository, do this:
cvs diff -u > /tmp/test1.patch
after which this can be applied to another fresh (or even modified) tree:
cat /tmp/test1.patch | patch -p0
assuming you were in the root directory of the project. Great way to bypass
CVS if you don't want these changes to appear in CVS yet.
wget http://ftp.gnu.org/non-gnu/cvs/source/stable/1.11.23/cvs-1.11.23.tar.gz tar zxf cvs-1.11.23.tar.gz cd cvs-1.11.23 ./configure make make installat which point the CVS software should be installed in /usr/local/bin. Obviously you'll need to be root for this. (April 2002: one problem we had is during the make, compilation complained about a missing krb5.h file. This seems like a configure bug; to fix it edit config.h and comment out the HAVE_GSSAPI line near the bottom and make again).