Re: versioning file system
On 10/26/18 3:26 PM, David wrote:
On Sat, 27 Oct 2018 at 08:23, David Christensen
<dpchrist@holgerdanske.com> 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
Reply to: