Re: [PLUG] Revision Control for the Rest of Us

[Rich Kulawiec <rsk@gsp.org>]

On Thu, Nov 16, 2017 at 10:47:29PM -0500, Rich Freeman wrote:
> One big difference between RCS and git (and probably several of the
> other modern VCSs) is that RCS is purely file-based (as is CVS, which
> is for the most part a layer on top of RCS).  If you make changes to
> 15 files and commit the changes, with RCS you get 15 files that each
> have a commit recorded in them.  They might have the same timestamp
> and author, but otherwise there is nothing that really links them. 

This is a feature and a bug.

The feature is that this means you can take an RCS delta file (like
foo.sh,v), pick it up, drop it somewhere, and then proceed as if it
had always been there.

The bug is that -- as you point out -- there's no "glue" between the
files.  If you modified foo.c and bar.c, depositing revision 1.3 of
foo.c and 1.5 of bar.c, and subsequently you separate those files,
nothing in either will lead to the other.

Combined with branching (as you discussed elsewhere, and yes, RCS
and CVS are pretty similiar in that regard) this means if building
release 1.0 of the foobar executable requires v1.3 of foo.c and v1.5
of bar.c, then that scrap of information will have to be recorded
somewhere else.  Makefiles are a good place for that, but a better
approach is to make all release builds dependent on the last version
of the default branch of each file, so that most of this happens
automagically, without requiring Makefile edits Every. Single. Time.


As an aside/adjunct to this discussion, I'm a big fan of using plaintext
files for everything possible and not a fan of the gratuitous use
of databases.   We now have systems that are ridiculously fast (for
tasks like revision control) and many of them use SSD storage that
alleviates some/much of the gap between memory and disk performance.
In the abstract, there exists no set of computing operations which
can be performed by DBs that can't be performed by plaintext files:
it's simply a matter efficiency, and the gap in efficiency has been
going down quickly.

Why do I mention this?  Because plaintext files are what I want to
have when things break, because they give me a fighting chance of
fixing the problem with vi and Python and grep and Perl and all the
other myriad tools that work with them.  When it's 3 AM and everything
is wonky and it needs to not be wonky by 9 AM, I'd much rather be
staring at text, even horrible text, than trying to unravel DB structures.

To relate this digression back to the discussion, I think that revision
control systems should eschew databases in favor of plaintext files at
every possible opportunity.  Whatever performance is surrendered by
that today will be regained in the not-too-distant future.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug