[sf-lug] Version Control :-) (Re: Who done it? ...)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] Who done it? ; -) Re: updated: Re: Status of  
> SF-LUG / Linux meeting(s) @ Noisebridge? & SF-LUG web site  
> (mis?)information thereof
> Date: Thu, 23 May 2019 19:28:32 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Well, as I'd also edited it (at least once now?), that'd be at least
>> two persons who'd edited it - at minimum - thus far.
>> http://linuxmafia.com/pipermail/sf-lug/2019q2/014118.html
>
> We all have to do with dumbness examples not of our creation, so this is
> absolutely not aimed at you, but just for giggles:
>
> Isn't the obvious solution to look at the version control history?
>
> Oh, _no_ version control.  Got it.

Well, the "who done it" was mostly just an illustrative exercise;
e.g. if I/we wanted to find out who made some change to some file ...

Yep, version control good.
Backups also good/important (whole 'nother topic).

"Of course" version control - at least in many cases, works mostly on
"honor" system ... but depends also upon what version control system
and how it's implemented in the architecture - some (or with
supporting infrastructure) effectively "force" version control
and the tracking thereof (including what ID did what changes and when).

As to version control ... nothin' prevents SF-LUG folk(s) from implementing
that on the web page - and even other web content there
(at least all those that have edit access to it):
$ hostname && id && ls -al
balug-sf-lug-v2.balug.org
uid=22035(sflugwww) gid=22035(sflugwww) groups=22035(sflugwww)
total 116
drwxrwsr-x  2 root     sflugwww  4096 May  9 18:43 .
drwxr-xr-x 21 root     root      4096 May 14 15:00 ..
-rw-r--r--  1 sflugwww sflugwww 35516 Sep  1  2008 LinuxKongSmall.jpg
-rw-r--r--  1 sflugwww sflugwww 35516 Dec  8  2006 LinuxKongSmall.jpg.test
-rw-r--r--  1 sflugwww sflugwww  2469 Sep  1  2008 functions.php
-rw-r--r--  1 sflugwww sflugwww    55 Sep  1  2008 index.html.test
-rw-r--r--  1 sflugwww sflugwww  3582 May 22 21:34 index.php
-rw-r--r--  1 sflugwww sflugwww  3864 Aug  3  2008 index.test
-rw-r--r--  1 sflugwww sflugwww  1994 Sep  1  2008 logo-servepath.gif
lrwxrwxrwx  1 sflugwww sflugwww    23 May  9 18:41 sf-lug.mbox ->  
/home/sflug/sf-lug.mbox
-rw-r--r--  1 sflugwww sflugwww 13542 Sep  1  2008 silicon_mechanics_logo.gif
$

I do use quite a bit of version control, ... e.g. lots of RCS (relatively
dead simple (mostly) & local); also do and/or have used many others
too (SCCS, CVS, Subversion, Git, some commercial stuff (e.g. ClearCase),
and probably some others too that aren't jumping to mind).
E.g. on that balug host:
# hostname && find $(mount -t ext2,ext3,ext4 | awk '{print $3;}')  
-xdev -name RCS -type d -print | wc -l
balug-sf-lug-v2.balug.org
19
# find $(mount -t ext2,ext3,ext4 | awk '{print $3;}') -xdev -name  
'*,v' -type f -print | wc -l
201
#

There's certainly lots more I could (ought?) have under version control.
E.g. more of the web page stuff & contents.  But too, it's often
a tradeoff of how much extra effort with version control vs.
probability of getting stuff out of it more than worth the
extra effort of doing the version control.  So, for better (and/or)
worse, there's also a lot that's not under version control.

Oh, and SF-LUG version control stuff?  Sure, there's some fair bit of that
I do - most notably the nominally overnightly SF-LUG list mbox &
roster ... bit more pain to set it up - but potentially
rather/quite useful - and also, once set up, about zilch to
maintain it - so the "pain" effort - all up front, mostly
all automagical (well, almost) after that.
$ hostname && id && cd && find * -xdev -name '*,v' -type f -print
balug-sf-lug-v2.balug.org
uid=29774(sflug) gid=29774(sflug) groups=29774(sflug)
bin/RCS/sf-lug_roster_stats,v
bin/RCS/sf-lug.mbox_rsync+version_control,v
bin/RCS/sf-lug_mbox_stats,v
bin/RCS/sf-lug_roster_fetch+decrypt+version_control,v
sf-lug.mbox/RCS/sf-lug.mbox,v
sf-lug_roster/RCS/sf-lug_roster,v
$
Yep, ... mbox & roster stuff, and code bits non-trivial enough,
also under version control (RCS).
See also:
https://www.wiki.balug.org/wiki/doku.php?id=sf-lug:resources_etc

Heck, for my Apache config on the balug VM, I've got (far? too?
much?!) complexity there (many virtual hosts, wiki, lists, soon(ish) to
add WordPress, ...) - not only lots of (RCS) version control,
but, I even have script to check what's not under version control
or is under version control, but file has change(s) not checked in
to version control:
# hostname && pwd -P && < .rcs_status expand -t 4
balug-sf-lug-v2.balug.org
/etc/apache2
#!/bin/sh

for f in $(
         find * -name RCS -type d -prune -print |
         sed -e 's/\/RCS$/\/*/;s/^RCS$/*/'
     )
do
     [ -f "$f" ] &&
     ! [ -L "$f" ] &&
     d=$(dirname "$f") &&
     b=$(basename "$f") &&
     if [ -f "$d/RCS/$b,v" ]; then
         if [ -f "$d/$b" ]; then
             (
                 cd "$d" &&
                 2>>/dev/null co -p "$b" |
                 >>/dev/null 2>&1 cmp - "$b" ||
                 echo "differ: $f"
             )
         else
                 echo "differ: $f (gone)"
         fi
     else
         echo "missing: $d/RCS/$b,v"
     fi
done
#
Uhm, yeah, that program expects the RCS stuff to be under RCS directory,
but wouldn't be horribly difficult to have it use ,v file in same
directory, or likewise under RCS/ directory (but I don't have that
need there).
# find . -xdev -name '*,v' -type f -print | wc -l
168
#
8-O
... well, some(/many?) of those are version control (history) of
files that no longer exist (but if I ever want to put 'em back ...)
But, yeah, I need to reduce my number of config files and structure
it better (rearchitech & update config) ... mostly notably it's
quite good - much use of Include and IncludeOptional to reasonably
cleanly separate out stuff for different (virtual) sites - so they
can be more conveniently added/enabled/disabled/removed,
and also much for doing otherwise redundant stuff via Include or
the like - rather than lots of repeats of same configuration sections.
But ... need to better clean that up so more of the redundant stuff
is consolidated, so there's then less separate files.

Similar for DNS zone master files & DNS server configuration
thereof:
# (cd /etc/bind && find * -follow -name .old -type d -prune -o -name  
'*,v' -type f -print) | sort
RCS/named.conf,v
RCS/named.conf.local,v
RCS/named.conf.options,v
master/RCS/balug.org,v
master/RCS/berkeleylug.com,v
master/RCS/berkeleylug.org,v
master/RCS/e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa,v
master/RCS/sf-lug.com,v
master/RCS/sf-lug.org,v
master/RCS/sflug.com,v
master/RCS/sflug.net,v
master/RCS/sflug.org,v
#

> So, memo to the assembled:  Step zero:  Add version control.
>
>
>
> I was just talking yesterday to someone on the telephone about typical
> conversations I kept having in early days with Windows users coming to
> LUG installfests, and am reminded of that on account of thematic
> similarities.
>
> User:  I want to do dual-boot.
> Me:  You must have been very bad.
> User:   Pardon?
> Me:  Sorry, I was almost-but-not-really joking.  Dual-boot unavoidably
>      introduces complications that personally I make a point of doing
>      without, and personally I think it'd be smarter for you to avoid
>      complicating your expensive, cutting-edge, and indispensible
>      Windows box, and instead play with Linux on that old machine
>      in your closet?
> User:  How'd you know I had a Pentium II in the closet?
> Me:  Because I'm writing this imaginary dialogue.
> User:  Oh, good point.
> Me:  Anyway, if you're sure you need dual-boot on _this_, then we at
>      the LUG will cheerfully not only help you hang yourself but also
>      furnish the rope, the beam, and any rope-making factories you
>      might want in case you run out of rope.  Plus a book on
>      knot-making.
> User:  Wow, your sense of humour's rather dark.
> Me:  Yeah, that's what Mom says, too.
> User:  But, can you reassure me that non-destructive partitioning
>      software is absolutely safe.
> Me:  It almost certainly isn't.  But that doesn't matter, because you
>      have a thoroughly tested backup regime and can confidently and
>      without worry restore if something bad happens.
> User:  No, I don't.
> Me:  Shocked, shocked.  Shocked, I say.  (Gambling.  Casinos.  All that.)
>      So, basically, now you know the very next problem you need to
>      solve before you do anything at all with your computer, let
>      alone take a figurative meat-axe to the C: drive.
> User:  Why would that be an emergency task?
> Me:  How much would you spend to buy a doorstop?
> User: Maybe a buck or two.  Why?
> Me:  What would it cost to replace all of your files from scratch
>      and completely rebuild from nothing the entire contents of your
>      hard drive?
> User:  A lot.  But what's this about doorstops?
> Me:  You just said, basically, if this or anything else blows
>      away the drive contents, the resulting loss would be a lot,
>      but the good news is that you could still use it as a doorstop,
>      so that's a lot less a couple of bucks.  Joy.
> User:  As I said, rather dark.
> Me:  That's what she said.
>
> Backups, yay.  Version control, yay, because backups.