Forum OpenACS Q&A: Re: Response to Upgrading packages

Ola,

Right on. I have never used CVS before, but your (very old) message inspired me to start. CVS is kind of mysterious and annoying-looking to the uninitiated, but it turns out that it doesn't take long to learn the basics.

For the benefit of other CVS novices, I was able to undertand most of the OpenACS references to CVS after a couple hours of reading the following:
1) http://www.loria.fr/cgi-bin/molli/wilma.cgi/doc.865331095.html
2) man cvs
3) Snippets from http://cvsbook.red-bean.com/cvsbook.html#A_Day_With_CVS

In the process of translating Ola's e-mail into actual cvs commands, I documented what I was doing, and I came up with the following, which is almost, but not quite, a runnable script (it assumes the existence of a user nsadmin and group web, for instance).

-Kevin Murphy

# First off, CVS can be used several ways in the context of OpenACS.

# 1) Obtaining OpenACS in a one-time shot. If this is all you use cvs for,
# you might as well just download the tarball.

# 2) #1 plus a convenient way of applying openacs updates to your local
# copy. If you use it for this, it's probably worth it.
# The main reason why this is superior to downloading another
# tarball and untarring it on top of your site is that ... you'd
# be crazy to do the latter, especially if you had modified any
# openacs core or package files. cvs lets you do _merges_ that you
# control (but don't do this directly on a live site!)

# 3) #1 plus #2 plus a way of backing up and maintaining your local
# site files and any changes you might make to the core openacs files.
# Now we're talking.

# 4) All the above plus a way of maintaining both a "development" and
# "production" version of your local site while retaining the ability
# to merge in updates of OpenACS. Feel the excitement!

# 5) Someday ... be an OpenACS developer with commit rights on the
# OpenACS repository. For this, using cvs is a requirement! In the
# meantime, report any bugs and your fixes to https://openacs.org/bugtracker/openacs/.

#
#
#

# The rest of this pseudo-script has the peculiar feature that comments FOLLOW the command.

#
#
#

export MY_PROJ=med

# Create an environment variable to hold your base web site/project
# name. This will be used later in the script.

su nsadmin

# The user who owns and runs aolserver

cd /tmp

# or wherever

cvs -z3 -d :pserver:mailto:anonymous@openacs.org:/cvsroot co -r oacs-4-6 acs-core

# Checkout the openacs core into /tmp/openacs-4
# -z3 means use compression level 3
# -d :pserver:mailto:anonymous@openacs.org:/cvsroot specifies the repository location
# co is a synonym for checkout
# -r oacs-4-6 is a version (release) tag
# acs-core is the name of the cvs module/project you want to checkout

cvs -d $HOME/cvsroot init

# You may not want to do this in nsadmin's $HOME if it is /usr/local/aolserver.
# If so, temporarily override $HOME in this script.
# Create a local cvs repository in nsadmin's home directory
# -d $HOME/cvsroot specifies the repository location

cd /tmp/openacs-4

cvs -d $HOME/cvsroot import -m "Creating initial local master repository of OpenACS 4.6." openacs-4 nsadmin initial

# Move the openacs-4 distribution into a master copy in your own local
# cvs repository. This master copy will be a backup of your
# development and production sites and help you manage your site
# development. As you build your site, your master copy will diverge
# from the original 4.6 distribution, mainly by the addition of your
# own files and changes to configuration files. If you find bugs in
# the OpenACS code, you can of course make fixes by editing the
# original files.
# *) "-d $HOME/cvsroot" specifies the location of your local
# repository for nsadmin.
# *) import means to recursively check in the contents of the
# current directory.
# *) -m "..." is the log message.
# *) openacs-4 is the name of the module/project to create in the
# repository.
# *) nsadmin is the "vendor tag".
# *) initial is a "release tag" which will allow you to distinguish
# between the initial set of files and a later configuration.

find $HOME/cvsroot/openacs-4 | less

# Verify what you've done

sudo mkdir -p /web
sudo chown nsadmin:web /web
cd /web

# /web is where you want your openacs projects to live.
# They don't actually all have to be in the same place, of course.

cvs -d $HOME/cvsroot checkout openacs-4
mv openacs-4 $MYPROJ-dev

# Check out an initial "development" version from your local
# repository. I repeat: you are not checking out from openacs.org but
# from your local master copy. As you make changes to the dev site,
# you can commit those changes to your local repository. When you are
# ready to go live, you can update the production site based on the
# changes.

cvs -d $HOME/cvsroot checkout openacs-4
mv openacs-4 $MYPROJ-prod

# Check out an initial "production" version from your local
# repository. Whenever you are ready to update your production site,
# do an update

export CVSROOT=$HOME/cvsroot
cat >>$HOME/.profile <<EOF
export CVSROOT=$HOME/cvsroot
EOF

# Set the CVSROOT environment variable to use the local repository as
# the default. From now on, you can skip the -d clause in cvs
# commands as long as you are making changes to your local repository
# or site directories. Whenever you do commands against the openacs
# cvs server, e.g. check for updates, you will have to take care to do
# them in your master repository directory ($HOME/cvsroot/openacs-4)
# and specify the "-d :pserver:mailto:anonymous@openacs.org:/cvsroot" clause
# to override the CVSROOT environment variable.