CVS

[Ben Pfaff]

Edward Glowacki <glowack2@msu.edu> writes:

> Hmm... that was easy... just got CVS to update between boxes using
> SSH... =)
> 
> setenv CVSROOT hurakan.cl.msu.edu:/home/CVS
> setenv CVS_RSH ssh

If you have more than one CVS repository then you'll probably
find that setting CVSROOT is kind of pointless and just end up
using cvs's -d option.  (But you only need it for initial
checkout anyway; after that it figures out the CVS root from
files in the CVS/ directories.)

> Now I just need to get comfortable using CVS, and set up all the
> CVS projects and such that I want to mirror.  I think I may try
> and write some sort of frontend to CVS and rsync that can be
> configured to use one or the other depending on the directory.
> That way I can sync my large documentation tree (python, zope,
> wxWindows, docbook, etc.) one way or the other (depending on which
> one I update first) using rsync (since I don't care about version
> control, nor do I want to allocate the extra space for it, pretty
> worthless), and sync my important and ever-changing documents and
> data using CVS, but have only one interface to worry about, say
> "xsync <directory>" and have it do the right thing.  Should just be
> a simple script to get me started:
> 
> #/bin/sh

Don't forget the
	if test -n "$1"; then
		cd $1
	fi
here, or you could be rather surprised sometime.

> if [ -f .sync_rsync ]; then
>     (put rsync commands here)
> elif [ -f .sync_cvs ]; then
>     (put cvs commands here)

I guess you won't want to be using CVS log messages then, if you
want all of your directories to have the same interface?

> elif [ -f .sync_command ]; then
>     (run .sync_command as a script)
> fi
> 
> Hmm... I can see this program getting big real quick... recursive
> syncs, syncs to different servers, etc... Guess version 2 will have
> to be better than a few lines of sh! ;)

I think you're thinking too hard.  You're talking about adding
intelligence to the script itself to figure out what server to go
to, etc.  I say that you shouldn't do it that way, you should put
these things in the dotfiles, not in the script.  

You could for instance just declare a single dotfile `.sync' as
the one for your script.  This dotfile would consist of
assignments to variables: shell commands.  The script would
source the dotfiles to set the variables.  It would source them
starting at the root directory and moving downward, so that you
could inherit defaults from the root directory and moving
downward.

Not to hard to implement, either.  The `for' loop is the only
part with any magic in it.  Something like this (untested):

#! /bin/sh

# Change to specified directory.
if test -n "$1"; then
	cd "$1"
fi

# Set up defaults.
mode=nosync		# no synchronization here by default
# ...			# whatever other defaults

# Iterate over each /-separated component of current directory
pwd="`pwd`"
for d in `IFS=/; set $d; echo "$@"`; do
	sofar="$sofar/$d"
	if -f "$sofar/.sync"; then
		. "$sofar/.sync"
done

# Do the deed.
if test "$mode" = nosync; then
	# Nothing to do.
elif test "$mode" = rsync; then
	# rsync commandsn here.
elif test "$mode" = cvs; then
	# cvs commands here.

# ...

else
	echo "Unknown sync mode '$mode'"
	exit 1
fi

exit 0

-- 
Aim to please, shoot to kill.