Simple Revision Control

I am not entirely sure I understand why one wouldn't use git for this role. If you don't need a remote git repository, you don't need to use one, and git will be available everywhere. Certainly many production machines will tend to have it for deployment of applications across multiple machines.

What are some use cases that don't work with git (which is probably already available on the system)? And why wouldn't git be an effective tool for that particular role?

I'm certainly not as experienced as ESR (though, I'm coming up on 20 years of administering Linux and UNIX servers), and perhaps I'm missing some subtle nuance here. I'm not wanting to come off as "screw this, this is stupid". I'm just genuinely not understanding why I should learn a new tool (or re-learn an old tool that's be "reloaded") when git does all of this and more...and I already know it and have it installed broadly across my systems.

hapless• 12 years ago

You are almost certainly more experienced than ESR. He held his last technology position in the early 1990s.

mwfogleman• 12 years ago

Then again, ESR has assumed a role in the free software community as a VCS expert, as evidenced by his reposurgeon project and uses.

jgrahamc• 12 years ago

There's a FAQ on this: http://esr.ibiblio.org/?p=6518

"Why SRC instead of $VCS?

Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."

SwellJoe3• 12 years ago

OK, but I don't see how git having those capabilities makes it inappropriate for cases where you don't need them.

I guess I can appreciate the single-file revision control thing, since that is something git doesn't do well. But, I am usually OK with a whole directory being under revision control.

All the other stuff is irrelevant, I'm pretty sure. Don't want branches and tags (I guess that's what "multi-fork" is referring to)? Don't use'em. Don't want multi-user? Doesn't matter, git doesn't lock files, and the user never needs to think about users if they are the only contributor to the repository.

vertex-four• 12 years ago

The point is managing single files, not directories. Want to version control your ~/.bashrc, for example? Or a single document? You can do that without having to move the file into its own directory in some hackish way.

shabble• 12 years ago

GNU Stow[1] referencing a git repo in ~/.dotfiles is what I use for that.

You might consider it hackish, but at least there are plenty of tools out there for managing it :)

[1] https://www.gnu.org/software/stow/

Karunamon4• 12 years ago

How is this different from just `init`ing the repo in your home directory and only adding files you care about?

mitchty• 12 years ago

You can always just set GIT_REPO_DIR to a bare/remote git repo and not have to move crap around if you don't want to.

git is a bit more flexible than how its normally used.

kazinator11• 12 years ago

I am not entirely sure I understand why one wouldn't use git for this role.

Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git.

For many users, using Git means cutting and pasting command line recipes scoured from desperate web searches, and crossing their fingers.

This does not go away when you use Git just for personal use with a repo that has no upstream.

ESR probably wants something that is simple to use for simple use cases.

debacle2• 12 years ago

computer science degree and years of experience to even begin to understand Git, for one thing.

Unless you're programming, in which case you should be able to understand git well enough, there are plenty of tools which completely abstract away the CLI interface (GitHub's is great).

click1703• 12 years ago

Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing.

With respect, I call shenanigans on this my good friend.

I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams.

I feel like this myth is perpetuated by a small group of people who are very vocal about "git is hard". If git commit and git checkout are too complicated, I don't know what else to say except that every VCS has those concepts, perhaps you're just used to those systems instead.

cschmidt3• 12 years ago

I sometimes use git this way on local files:

    git init                       # make a local repo
    git add foo.txt                # add the file
    [edit]
    git add -u                     # add changes to commit
    git commit -m"made a change"   # check in changes
    git log                        # see commits
    git status                     # what has changed

That's really all you need to know.

nhaehnle• 12 years ago

Git is one of those things where it pays off immensely to understand the underlying object model.

Learn about commit objects, tree objects, and file blobs. Then learn about the staging area.

There are some things layered on top of or next to this (such as stashing, pull and push), but understanding this small core is sufficient for everything else. I've worked on large problems and juggled many branches, and I've never had any problems.

Git gets the core concepts of distributed version control right, and this is the reason why it has won. Over time, everybody will be exposed to those core concepts, and the age of cutting and pasting command line recipes from the web will be over.

SwellJoe3• 12 years ago

So, "when I need something easier to use" would be your primary use case for this? Which would mean that for someone that knows git reasonably well already, they would have no use case for this software? After all, learning a wholly new tool is harder than using a tool you already know.

kazinator11• 12 years ago

There is already a very decent little single-user revision control system that is light-weight and well-suited for making changes to individual files.

Namely: the Quilt patch management system.

http://en.wikipedia.org/wiki/Quilt_%28software%29

In quilt, your revision history is a "stack" of patches which is applied to the tree. You can push and pop up and down the stack, and revise the patches (for instance, to migrate them to a different version of the tree, or just to make them more perfect).

viraptor• 12 years ago

Quilt is good for managing patches - as in applying or removing them if you know they do apply. But from what I experienced, doing anything else with it is a world of pain. You actually need to say which file are you going to change before changing it! Handling git merges/rebases seems to be a walk in the park compared to fixing quilt patches that don't apply anymore.

I wouldn't say it's useful for individual files either...

muyuu3• 12 years ago

Depends on Bash which is not popular in many platforms, builds with autoconf. My granny is not going to use Quilt.

debacle2• 12 years ago

ESR, is, if nothing else, the champion of his own relevance. I've never really been fond of his work, though he seems like a nice enough guy.

But he's just another OSS hacker. Bruce Perens has accomplished far more with far less controversy and self-fluffing.

comice• 12 years ago

"ESR, is, if nothing else, the champion of his own relevance"

wonderful.

GFK_of_xmaspast4• 12 years ago

"a nice enough guy"

Nope:

http://esr.ibiblio.org/?p=26

jayvanguard• 12 years ago

Yeah, I unsubscribed from his blog "Armed and Dangerous." He thinks he thinks he is smarter and more knowledgable about general topics than he really is.

It should be named "Just Enough Knowledge to be Dangerous."

Logic only gets you so far when your base of knowledge is very limited in a subject.

pothibo3• 12 years ago

Thanks for the link. He actually compares homosexual with pedophiles. I want to have absolutely nothing to do with such a degenerate.

sigzero• 12 years ago

That is from 2002. Does he still hold those views?

_delirium• 12 years ago

See also his attempts to take credit for other people's work on ncurses: http://invisible-island.net/ncurses/ncurses-license.html. I don't think I would want to work with him on a project.

hughw• 12 years ago

There's nothing un-nice about that article. It's a reasoned argument. You may disagree with its conclusion, and you can write your own refutation of it. But it has nothing to do with ESR's niceness.

GFK_of_xmaspast4• 12 years ago

Eric Raymond, everybody: "Nor is it any good thing that “youths” now behave as though they think they’re operating with a kind of immunity. We saw this in Ferguson, when Michael Brown apparently believed he could could beat up a Pakistani shopkeeper and then assault a cop without fearing consequences. (“What are you going to do, shoot me?” he sneered, just before he was shot) As he found out, eventually that shit’ll get you killed; it would have been much better for everybody if he hadn’t been encouraged to believe that his skin color gave him a free pass."

It’s not clear to me that this kind of indulgence is any better – even for blacks themselves – than the old racist arrangement in which blacks “knew their place” and were systematically cowed into submission to the law. After all – if it needs pointing out again – the victims of black crime and trash culture are mainly other blacks. Press silence is empowering thugs."

wglb• 12 years ago

And there is this: https://lists.debian.org/debian-devel/1999/04/msg00197.html

bhaak2• 12 years ago

ESR, is, if nothing else, the champion of his own relevance

What an apt description. I never have had much confidence in the coding that ESR has done. Just look at fetchmail and how that one has lost uncountable mails because of poor design.

Although he seems to think highly of his coding skills but I always had the impression that he's one of those hackers that really just hack together solutions. If a problem comes up there's always a fix to be committed. I wouldn't want such a programmer on my team.

But he's always been good with words and as an OSS lobbyist he was a well needed figure that put the software first and not politics as RMS did.

snoopybbt• 12 years ago

Yeah, sure. I'm definitely going to use it. Sure. Trust me.

mrb• 12 years ago

He claims he did not use Mercurial because (a) it stores the history in binary blobs, (b) it does not have sequential revision numbers, and (c) its CLI syntax is ugly, see [1]. Unfortunately he is wrong about (b) and (c). Mercurial assigns automatic sequential revision numbers (perfect for a single non-distributed repo) and its CLI syntax is so neat that this is the reason I do use it a lot to track changes to single files...

Sounds like ESR should have spent a little more time studying Mercurial.

I cannot understand his need for (a). Does he want the possibility to quickly and easily see, or edit the history? If it's only seeing it all, in one command, then a simple "hg log -e" does it.

[1] http://www.catb.org/~esr/src/FAQ.html#another-vcs

Edit: @leoc I based my comment on "Other projects to mold Mercurial and Git [...] will fail criteria #3 and #5, and often #4 as well" with #4 referring to a "modern CLI syntax". But yeah it could be implied that this criticism does not (always) apply to Mercurial.

leoc• 12 years ago

From TFA:

4. Modern CLI user-interface. Commands familiar to Subversion, Hg, Git users.

Doesn't seem that he's down on Mercurial's syntax.

xixixao• 12 years ago

[Modern CLI user-interface.] [Commands familiar to Subversion, Hg, Git users.]

Those two just make up an oxymoron for me.

e12e• 12 years ago

I'm nit particularly fond of git, I much prefer mercurial - but they are of course pretty much equivalent. Either way I have a hard time seeing which usecases aren't covered by the duo of RCS and mercurial (actually I'm very hard pressed to see why one would ever use RCS over mercurial, but no question RCS is simpler). At least something like fossil have some actually unique features....

bryanlarsen• 12 years ago

That was ESR's conclusion as well. SRC is just a simple wrapper around RCS.

pbreit• 12 years ago

To a newbie, they don't seem that equivalent. Mercurial is much easier to understand, imo.

wbkang• 12 years ago

This is the first time I read that Mercurial's CLI is ugly

awalton• 12 years ago

I think in a strange way, this tool is actually not a terrible idea. Git is not a configuration management tool, no matter how hard people try to shoe-horn it into that role. A simpler Git designed for configuration management is indeed a good idea.

Unfortunately, I think the implementation leaves a lot to be desired. For one, not including the committer is an important flaw. If you're only managing your own system's configuration, it makes sense, but surely ESR realizes that UNIX-based OSes are multiuser systems, often administrated by teams of people. Being able to track whodunnit is definitely an important part of the equation. (It'd be incredibly clever if it signed the log with the user's public key too, but that might be asking a lot.)

Needing something like SRC to track changes to a simple README or HOWTO? My local bin dir? Ehh not so much. Especially if it's a software project? No, that definitely should live in the VCS with the code, so that those who touch the code will also touch the documentation. It says a lot about src that it doesn't even live in a src repository.

muyuu3• 12 years ago

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle.

I routinely use my own rdiff/rsync scripts but this is not something you find in every system and also not something most people would use.

A barebones, simple, no-install, easy, not-necessarily-for-experienced-developers VCS is a good thing to have.

BTW it's going at 1 release per day. Heh :-)

npsimons2• 12 years ago

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle.

Here's the thing that's funny to me: git is easy. Everyone (especially mercurial users) goes on about how horrible the UI is, but when I think of git, I think of how similar it is to RCS: easy, quick, and simple. With both, I can diff things and check in changes very quickly. I have a bunch of single files in RCS which I'm moving over to git because it's a no brainer: all the speed and ease of use with a ton of advantages (such as dead simple replication) if I ever need them.

skywhopper• 12 years ago

Nothing stopping shops from writing a simple wrapper to add commiter ID and signature in a machine-readable standard way to the commit messages. Sure that could be easily gotten around. So can git's.

fetbaffe4• 12 years ago

It is a great idea. Git is just too much of an hassle when you only have one file of TODOs, a tiny hack or what not. Why bother with checksums when an incremental integer helps me memorize what revision I'm on?

However as others has pointed out, maybe the dependency on rcs was not the best choice.

icebraining5• 12 years ago

There's life beyond git, though. Bazaar gives you incremental¹ integers and a much nicer UI.

¹ barring merges, but those shouldn't happen in these use cases

bhaak2• 12 years ago

I can see the need for a VCS that doesn't grab the whole directory but is file based.

But this "SRC is built on top of RCS" doesn't sound like the best idea. RCS has been historically more errorprone than SCCS, probably because it doesn't use a checksum in its history file. So you never know if there has been a corruption or not.

Even though he mentioned SCCS "SCCS died off due to its proprietary nature", he doesn't seem to be aware that the Solaris version of SCCS got open sourced: http://sccs.sourceforge.net/

towelguy• 12 years ago

Aparently you need the rcs and rcsdiff commands available to use it.

peterwwillis• 12 years ago

At the very least I would have liked to see some kind of minimal global index of changes. With single-file vcs, you may have a large tree littered with .src files, and you have to walk to the whole tree just to find all your revision controlled files. By [also] storing them in a global index you could simply list all revision controlled files, then perform operations on them all or on parts of them, without having to 'find' each time. That could default to $HOME/.srcidx so you never have to initialize some root tree or track an environment variable.

dzsekijo3• 12 years ago

I don't get how git (or any proper multi-file dvcs) falls behind facilitating the purpose ESR is shooting at. You can use "git log <file>" to track changes of <file>.

It's like Gmail drafts. While it's delivered to you as an email stashing feature, I realized that it's the best cloud-based (offline-synced, omnipresent) note application. It can do that even if "note" is not in its name. We can be creative about using the tools at our disposal.

Besides (back to the original problem), it can be handy sometimes that you have a tool that can operate over the whole range of managed files, even if they are logically unrelated.

crazygringo• 12 years ago

I don't know about this tool, but git does not make it easy to move files from one repository to another, for instance, and maintain that file's history.

Heck, I'd like to be able to e-mail a single file to someone, and have the file keep its revision history. File-based revision histories, as opposed to repository-based, have a whole host of advantages that come from flexibility.

dzsekijo3• 12 years ago

git also has good support for explicit cutting down the repo to a subset of its files, or merging back changes of a partial repo to the common one, see filter-branch and subtree commands.

jxf2• 12 years ago

Here's a very obvious use-case: You have a single file with many historical changes. That file moves to a new directory that is not a subdirectory of its current directory.

In git, the file vanishes from the repo and can't be tracked easily anymore. You lose all of its past history if you put it into a new repo. In SRC the history moves with the file.

aidenn0• 12 years ago

the .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.

jordigh4• 12 years ago

What if you'd like to track files at your filesystem root? /.git would be a tad complicated, since you'd need fairly complicated .gitignore rules, right? You wouldn't want "git status" or "git diff" to read your entire filesystem, including all mounted devices.

dzsekijo3• 12 years ago

"git status" recurses only into those dirs where there is managed content. "git diff" restricts its operation to managed files.

That said, if you are into managing particular files and not a file tree, most likely you'd consider all info about other files than the chosen ones to be noise, which can be expressed in .gitignore in a very succinct way: '*'.

sparticvs• 12 years ago

Sounds like someone misses DEC VMS's method of revision

GFK_of_xmaspast4• 12 years ago

I sort of do.

dmd• 12 years ago

See also https://github.com/rupa/rvn (not to be taken seriously). (By the author of z, possibly the most time-saving unix tool ever created).

ansible• 12 years ago

For this niche, I use vcsh:

https://github.com/RichiH/vcsh

I've been using git for years at this point, so I'm glad to leverage my existing skill. It also ties into my existing setup for SSH, so that I can push and pull changes from a central server. I like this because I regularly work on two different desktops, a laptop, and a few other machines.

coned88• 12 years ago

What's wrong with RCS?

jarun• 12 years ago

How about fossil? http://tuxdiary.com/2013/09/20/fossil/

Simple Revision Control

Related Stories