CVS
Edward Glowacki
glowack2@msu.edu
Wed, 27 Jun 2001 15:40:40 -0400
Quoted from Ben Pfaff on Wed, Jun 27, 2001 at 11:30:13AM -0400:
> 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.)
Yeah, I realize that, those were just the steps I took in the
specific example to get SSH to work.
> > 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.
I nixed that idea entirely and wrote up the specs for a real
program to do what I really want instead of a half-implemented
shell script. =)
> 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?
I don't think I want to cripple the underlying tools in any way,
and usually each directory is only going to have one method for
synchronization, so if it's using CVS it would know about the CVS
logs and "do the right thing" already without my intervention. I
may pipe all the output from commands to a file or something to
keep it from showing up on screen, but if CVS wants to make its
own log file, I guess I don't really care.
> > 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.
Like I said, that was just a starting point, my 30-second attempt
to write what I was thinking. I have since drafted some real specs
for it (which I'll attach at the end of the message).
> 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.
Pretty much what I was already thinking.
> Not to hard to implement, either. The `for' loop is the only
> part with any magic in it. Something like this (untested):
Might try to do it in something other than shell language, since
my idea has grown a bit into something larger than I'd feel
comfortable doing in sh.
Anyways, here's the basic design I've come up with. There's still
some things to be worked out and things to add, but I think most
of the concepts are there. Any input is welcome!!! Maybe this
will actually be useful to someone else out there if I build it
right... =) So fire away, shoot holes in my ideas, tell me I should
write the whole thing in sed or FORTRAN, bitch about the cheesy name,
tell me to write it in C# with a JAVA frontend and IPv6 support,
whatever (hehe, I don't have to listen to you if I don't want, but
having too many ideas and throwing some out is better than not
having enough ideas... =) ).
=================
Easy Sync (esync)
=================
Overview
--------
esync will be a handy frontend to rsync, CVS, and optionally probably
any other sync tool (ftp mirroring tools, web site sync tools,
etc.).
The target audience for this application is not hard-core users of
CVS or other sync utilities, but rather those people that know a little
bit about them and have need to use several different sync/backup
strategies for different things. It can cover up the details of the
different implementations under a homogenous interface, so the user
doesn't have to learn the ins and outs of each system. It should be
easy to use, with online help (including examples!) and user input
error checking and validation.
Basic operation
---------------
Basic operation involves checking directories for .esync files,
which are then read in to determine the method to be used for
syncing that directory. For example, .esync might contain the
following lines for use with CVS:
METHOD CVS
REPOSITORY hurakan.cl.msu.edu:/home/cvs
RSH_CMD ssh
and when run, esync might do the following
setenv CVS_RSH ssh
cvs -d hurakan.cl.msu.edu:/home/cvs update
cvs -d hurakan.cl.msu.edu:/home/cvs commit
To sync using rsync, .esync might contain:
METHOD RSYNC
REPOSITORY hurakan.cl.msu.edu:/home/cvs/test_directory
and when run, esync would run something like:
rsync -a . hurakan.cl.msu.edu:/home/cvs/test_directory
Config options
--------------
.esync options
METHOD - CVS, RSYNC, (other modules added later)
REPOSITORY - Location to sync with in the form of user@host:path
USERNAME - User name
PASSWORD - Ack, I don't like this, but it might be needed...
set to ASK to be prompted?
RSH_CMD - For methods that support it, force rsh to this command
Note: rsync uses ssh by default, CVS uses rsh by default,
and esync will use ssh (overriding CVS unless RSH_CMD is set)
OPTIONS - Recursive/nonrecursive, push (change only repository),
pull (change only local), quiet/verbose, backup (make backup
copies before updating [rsync only?])
DATE - Automatically updated after each sync to show last time
the directory was updated (2 dates, one push, one pull?)
CONFIG - Name of config file to pass to sync tool
NOTES - Additional information, has no effect on backups
.esyncrc options
GROUP - name=directory,directory,directory (.esyncrc file?)
METHOD - default method
REPOSITORY - default location
USERNAME - default username
OPTIONS - default options
module config commands
COMMAND - /usr/local/bin/rsync, etc.
(all options) - how to do each option (--recursive, --username=%s, etc.)
Commands
--------
These commands are available for esync and take the form:
esync <command>
Commands Description
-------- -----------
ls - list directories with their date, method, and repository
Example:
docs 2001-06-15 23:15 rsync hurakan.cl.msu.edu:/home/cvs/docs
thesis 2001-05-20 13:13 cvs hurakan.cl.msu.edu:/home/cvs
data 2001-05-23 14:12 cvs /home/cvs
temp Never none
book 2001-06-15 23:20 cvs hurakan.cl.msu.edu:/home/cvs
galeon 2001-05-20 20:00 cvs anonymous@anoncvs.gnome.org:/cvs/gnome
edit - change parameters for a directory
update - run the update
version - display esync, cvs, and rsync versions (and other modules)
test - test connections
(no command) - show version and help
interactive - interactive mode?
new - setup directory using defaults
--
Edward Glowacki glowack2@msu.edu
GLLUG Peon http://www.gllug.org
Imagination is the one weapon in the war against reality.
-- Jules de Gaultier