Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!altos86!dtynan
From: dtynan@altos86.Altos.COM (Dermot Tynan)
Newsgroups: news.software.b
Subject: Re: C News production release bugs
Summary: Not a good plan...
Message-ID: <1299@altos86.Altos.COM>
Date: 16 Jun 89 23:50:57 GMT
References: <1989Jun13.034954.144@utstat.uucp> <3309@epimass.EPI.COM> <1989Jun13.211659.11139@utstat.uucp>
Organization: Altos Computer Systems, San Jose, CA
Lines: 52

I can't say that I agree with you on your ideas of version control.  However,
I *do* have to admit that YOU are the one who did the work, and all I can do
is comment.  With that said...

In article <1989Jun13.211659.11139@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes:
> Henry and I discussed modifying version numbers and the like yesterday,
> but decided that we don't want to *have* multiple versions of C news in
> the field, if we can avoid it.  (We don't particularly like version
> numbers like C news 3.11vr2 and do not want to buy into the patchlevel
> bureaucracy, since it encourages patches by making them easy.

I agree with your first statement.  Multiple versions are rather painful.  As
evidenced by the "#ifdef OLD" stuff in B news.  However, not buying into the
patch phenomenon (which, by the way, I consider a fascinating piece of code!)
because it encourages patches, can be compared to current controversies over
contraceptives encouraging sex.

> We want C
> news to rapidly converge on a stable version.)  One can distinguish the
> initial production distribution from the updated one by size or by
> grepping for "/relay" in relay/aux/mkpdir; it you find one, you have the
> updated one.

When a product (such as C news) goes into mass-distribution it is only
natural that some problems will be found.  Even with extensive beta-site
testing.  This is the legacy of Murphy.  Trying to identify what version
one has, is *very* easy when one can look at 'patchlevel.h'.  Having to
grep for keywords is not a very good revision policy.  Ask Andy Tanenbaum
about the problems associated with 'size' comparisons.  I doubt you will
find many sites which have similar sized archives, for whatever reason.
Having patchlevels ensures that a) patches are applied, and b) that they
are applied in the right order.

> Consider also that yesterday's fixes (ignoring updates to comments)
> amounted to moving 4 lines of code, changing 2 lines, and adding 1 line.
> If you don't trust the patch program to apply the context diffs, it's
> easy to fix the sources by hand.
>
> Geoff Collyer		utzoo!utstat!geoff, geoff@utstat.toronto.edu

What you can do, is use patch to apply the changes, and diff the file against
file.orig.  If the changes aren't too extensive, you can thus audit the
work done by patch.  I find this much more reasonable than trying to apply
patches by hand.  Usually, though, patch will complain if it finds anything
wrong.  Therefore, if you run it, and it completes quietly, you can be pretty
confident that the changes were made correctly.  Comments...
							- Der
-- 
My address:	dtynan@altos86.Altos.COM	(Hopefully!)
Otherwise:	{altnet,amdahl,pyramid,sun}!altos86!dtynan

  ---  "May the blessings of Jeyes Fluid fall upon you"  ---