Question: C-news & /bin/mail

[Greg A. Woods]

[ This (long) article addresses a much wider problem, and thus I've
cross-posted it to comp.sources.d and comp.unix.programmer.  Perhaps
followup's should be re-directed too, but I'll let someone else do
that! ]

In article <1990Dec30.032132.10805 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
> In article <1990Dec20.150245.28078 at progress.com> erf at progress.COM (Eric Feigenson) writes:
> >    Is there something I'm unaware of in the patch/install process that
> >    would inhibit installing over something that I've changed and alert me
> >    so that I don't have to tax my feeble brain and remember exactly where
> >    I've made changes?  I admit it; I'm lazy.
> 
> This is a difficult problem, and one that we unfortunately have no magic
> solution for.  Maintaining local modifications in the presence of patches
> that (necessarily) assume unmodified software is just plain awkward.

Well, depending upon the extent of the local modifications, it *can*
be quite easy, iff you are using a version control system such as SCCS
or RCS.

Depending upon the divergence of the local and original sources, often
patch can deal with the differences, and where conflicts arise, the
reject files show the problems.  However, for more complex changes, as
long as the file structure remains similar, SCCS and RCS can merge
versions and identify conflicts.

On my currently dead machine I had modified 99% of the shell scripts,
all of the Makefiles, and even some of the documentation, but hardly
any of the C code (only one bug fix, I think).  However, I still have
the original versions of any modified files as SCCS delta 1.1, and all
files I had modified were checked out as branches 1.1.1.1.  If I want
to install a patch to a modified file, I first delta my changes back
to 1.1.1.1, then 'get -e' 1.2 from 1.1, and patch it, then delta it
back; then I 'get -e' 1.2.1.1, merging 1.2 and 1.1.1.1 (i.e. with
'-i1.2,1.1.1.1'), which would hopefully be the new version *with* my
local changes already merged in.  If there are no conflicts, I delta
it back and I have the patch installed, with my changes.  If there are
conflicts, I edit before delta'ing.  I can even use the %R% (release)
numbers to identify completely different versions of files where
merging would not be practical.

This process can easily work for multiple files, thus patching a whole
"system" at once, and can work for multiple simultaneous patches too.

BTW, I use Allman's sccs, thus Makefiles don't need any changes, since
all of the current working versions for all files remain checked out
in the same relative place as the originals.

The only thing to be aware of is that local SCCS SID's have no direct
relation with patch numbers/dates, and even vary between files.  I do
not create an s. file for everything in a "system", but only for
locally modified bits.  Patches get installed in original, un-modified
files with no local change history.  In fact, with SCCS major deltas
can be deleted after the merged version is delta'ed, since all it does
is take up space.  The original patch, if kept, can reproduce it from
the current major version (i.e. 1.2).

Just before the lightning strike I was in the process of tearing apart
all of the patches beyond my current patch level, separating those
for the C code changes, and the changes for the scripts, etc.

My intention was to patch all of the C code with right away, since I
reasoned that the fixes there-in would be most valuable, and the
number of conflicts would be few.  There also seemed to be little
inter-dependence between the changes in the C and changes in the
scripts.  This was exceedingly tedious work, but I didn't want to
think about it enough to automate it.  I wanted to be able to (test
and) install the C code patches in advance of the script patches.

Then I would go back check out the original versions of the scripts,
patch them, then merge my branch changes back in, being very careful
to heed SCCS's warnings about conflicts, and also being very careful
to read each script after patching it, to be sure it still did what
*I* wanted it to do.  By patching the original, then re-applying my
changes, it should be at least close to being correct.  The subsequent
checks and read-through would verify the new version.

The main reason I had not installed the most recent 6 or 8 patches was
that my system was running solid without any direct attention to news
administration for months, and it seemed no new features in patches up
to last August were of sufficient importance to make the change.  I
believe it was/am at 13-Nov-1989.

The primary change I made to almost every script and Makefile in C
News was to eliminate the use of 'subst', which massively messes up
any attempt to use SCCS or RCS, since it modifies "production"
versions of scripts prior to installation.  I now use a new subst as a
filter on a '.sh' file, dropping the extension to create the installed
version.
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL