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.

Perhaps.


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

git-cat-file(1)
git-grep(1)
git-diff(1)

    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:

    https://en.wikipedia.org/wiki/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

CVS WTF? :)

Yup.


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.

git-rebase(1)

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.)


David