rfinch@caldwr.water.ca.gov (Ralph Finch) (06/14/91)
A new rcs.el interface is available for testing. It's unfair, because
I have not been able to thoroughly alpha-test it here first, so I'm
calling it an alpha-beta test. (I use it daily but have not had time
to systematically test all of the features). Neither have I had time
to write a good description of it. I'm releasing it for test simply
because there might be a few brave people willing to put up with the
above nonsense in exchange for what I think is really a nifty rcs
interface.
If you want to try it, it's available via anonymous ftp from
water.ca.gov, as pub/rcs.el.shar.Z. If you don't have ftp access,
send me email, I'll email it to you.
If you're interested in an emacs rcs interface but want one that's
reliable, WAIT. Let this one be debugged first. After debugging I'll
post another message.
USER BEWARE! Neither the authors nor their employers accept any
responsibility for damage or loss or any other bad thing caused by
using this program. Test and use at your own risk. It would be wise
to keep backups of programs you checkin/checkout with this interface.
Please send bug reports to 2 people:
rfinch@water.ca.gov jat@water.ca.gov
This interface works ONLY with RCS version 5.5 or later.
Here's the README file:
This works *only* with rcs version 5.5.
The interface is a greatly extended version of Chris Siebenmann's
rcs-cks.el interface released some time ago. The philosophy was to
make it easy for fairly naive Unix and RCS users to still create and
use multiple branches and merges. Extensions are:
1) Tag files co, ci. See functions rcs-co-tags, rcs-ci-tags,
rcs-make-variation-tags.
2) Branches for individual users automatically created and used for
each user who wants the functionality. See variable rcs-use-user-branch.
3) Variations within each user branch; users can maintain multiple
branches for multiple projects on the same files. See function
rcs-make-user-variation, variable rcs-add-all-symbolics. To do
this the source codes for each variation must be kept in different
directories.
4) Menu control of branches, variations, and merges. See function
rcs-interactive-variation-menu.
5) Merges done with the emerge.el program by Dale R. Worley,
drw@math.mit.edu.
6) Checkin of all checked-out files in a directory. See function
rcs-ci-checked-out.
7) Don't force checkin if a file hasn't changed.
(6 and 7 allow a user to checkout all files in a directory for a
project, modify just some, then automatically checkin the changed
ones).
Recommendations: I bind just 2 additional keys:
(define-key global-map "\C-c\C-f" 'rcs-co-file)
(define-key global-map "\C-c\C-s" 'rcs-ci-buffer)
Additionally, I set the following variables:
(setq rcs-ci-buffer-kills-buffer t)
(setq find-file-hooks (list 'rcs-hack-modeline))
(setq rcs-edit-mode 'text-mode)
(setq rcs-initial-access "user1,user2,user3"))
Also, here's how we handle multiple users on the same source:
For program A, we create a main directory and put the source code and
RCS subdirectory there; call it .../main_A/A.c .../main_A/RCS/A.c,v
But, we don't edit those source codes! Instead each user creates
their own analog of the main directory structure: .../user_A/A.c
However, instead of creating an RCS subdirectory, the user links back
to the real one: ln -s .../main_A/RCS
This way there's just one copy of the ,v files, but user copies of the
source code. This interface handles copying versions around.
Please send bug reports to both:
rfinch@water.ca.gov jat@water.ca.gov
--
Ralph Finch 916-445-0088
rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWR