Web lists-archives.com

Re: versioning file system

On 10/26/18 3:26 PM, David wrote:
On Sat, 27 Oct 2018 at 08:23, David Christensen
<dpchrist@xxxxxxxxxxxxxxxx> wrote:

Hi, I've noticed that you give a lot of good advice on this list. Now, I hope
to return the favour :) ...

Thank you; I try.

When I'm working on a file, I can do ten edit/ saves, or more.  With a
versioning file system, the original file plus all the saves would be on
disk.  This makes it easy to pick through them using standard tools.

git is a "standard tool" these days.


But if the original file and all but the last save are in a version
control system (VCS), I would need tools that can reach inside the VCS.
Searching the manual pages of cat(1), grep(1), diff(1), and make(1) for


    cvs update -p ...

    cvs diff ...

The first operation for both Git and CVS is necessary functionality (print a specific revision of a file on standard output). The second and subsequent operations can be performed the Unix Way:


    cvs update -p ... | grep ...

    cvs update -p ... | diff - ...

    cvs update -p ... > ... && cvs update -p ... > ... && diff ...

A versioning file system exposes every version of file as a regular file, so that every file system aware tool can access it.

A good shell lets you easily combine the files and the tools as desired.

'CVS' just now, I found zero hits.  This means I'd need to check them



out.  Now I'm back to what a versioning file system gives me automatically.

Furthermore, auto-commit on every save would put a lot of cruft into the
VCS, to be stored, backed up, and archived repeatedly and indefinitely.
If I try to remove the VCS auto-commits by hand, eventually I will
damage or destroy the VCS repository (e.g. Murphy's Law).  Removing VCS
auto-commits mechanically would require developing and validating a
suitable work flow and tools, adding cost and limiting flexibility.


Seriously, learn git. git's own documentation does not make that easy, but
if you search more widely for information and persist, it will be extremely
rewarding in the long run.

I read the O'Reilly book "Version Control with Git" many years ago, but I haven't had a compelling use-case for Git. (And, I prefer CVS's traditional per-file version numbering feature.)