
Simple Revision Control - jordigh
http://www.catb.org/~esr/src/
======
awalton
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.

~~~
muyuu
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 :-)

~~~
npsimons
_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.

~~~
encoderer
I love git. I'm a git power user. I've used git as the datastore for a CRM I
built.

But I respectfully disagree. Git is not "easy." You've been conditioned. You
and I know that it's very very hard to lose work or lose commits with Git. I'd
say it's nearly impossible to do on accident. But in my first month with Git I
rewrote several things because I messed up somehow and couldn't figure it out.
I would hose my checkout and resort to doing a new clone. I've since helped
run a big transition from SVN to Git and saw the same struggles there.

Git is power tools for my code. I could never go back to SVN. But it's not
easy.

~~~
w_t_payne
I agree. Git is powerful, flexible, and (once you grok it) quite simple to
understand ... but it baffles new users, and is a complete turn off for people
who happen not to be software engineers, even those who are otherwise highly
intelligent.

I work trying to bridge the gap between a team of mathematicians and
algorithms engineers, and a team of embedded software engineers. Most of the
embedded software engineers "grok" git (after some practice), and are (fairly)
happy using it on a day to day basis.

The Mathematicians and Algorithms engineers, on the other hand, aren't really
interested in getting to grips with Git (or any version control system for
that matter). They'd rather spend their time thinking about mathematics and
statistics. (Quite rightly).

The decision to use git, whilst justifiable for many valid technical reasons,
has definitely thrown up some additional challenges for me and for our
organization.

------
mrb
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](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.

~~~
e12e
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
That was ESR's conclusion as well. SRC is just a simple wrapper around RCS.

~~~
kazinator
If you want a simple wrapper around RCS (or at least RCS semantics), why not
just use CVS.

CVS has sequential numbers. Well, sort of: 1.1, 1.2, ... unless you branch.
Close enough.

It works with individual files well enough (and in fact not all that well with
clusters of them).

CVS started in 1986 as in fact a shell-scripted wrapper around RCS.

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

~~~
kazinator
_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.

~~~
click170
> 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.

~~~
pjc50
git commit and git checkout are fine. git pull and git push are where the
problems start.

 _as I got myself into tighter and tighter jams_

I suppose this is the thing; if you're happy to learn that way, fine. It's
just that git is particularly prone to "I've trashed local state and lost
work" / "I've just pushed a huge mess and will have to lose time cleaning it
up, if that's even possible".

~~~
ibrahima
I love git, but even git checkout is asinine. It's fine for checking out a
tag/branch/rev/treeish, but why on earth does it also revert files to their
checked in state if given a path argument?

I don't think git should be prone to trashing local state due to how it
usually yells at you when it's about to do that, but then I've been working
with a student this quarter who seems to do that every time I push something
to github and she needs to pull. I think if the git community got together,
did a usability study on how people actually use git, and renamed/split out
commands into names that made sense, it would be a huge boon for general
usability.

~~~
kazinator
> _why on earth does it also revert files to their checked in state if given a
> path argument_

Simplification! :) "git checkout file" reverts a file from the index. If it
doesn't exist in the index, then from HEAD.

The problem is that you can make a typo, because branches, tags and files are
all in the same namespace. Suppose you wanted to type "git checkout foob"
which is a tag or branch, but instead you make a mistake and type "git
checkout foom" which is the name of a file that happens to have unstaged
changes. Oops!

If "file" has unstaged changes, then "git checkout file" should rename it out
of the way first to "file.#1#" or whatever. (Hello, look at CVS!)

------
mateuszf
Chosen name "src" is quite unfortunate, as it will be a src of confusion.

~~~
rsanheim
Agreed, such a horrible name choice.

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

~~~
dzsekijo
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.

------
aw3c2
Much better link is
[http://www.catb.org/~esr/src/](http://www.catb.org/~esr/src/)

~~~
dang
Ok, we changed to that from
[http://www.catb.org/~esr/src/README](http://www.catb.org/~esr/src/README).

------
bhaak
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/](http://sccs.sourceforge.net/)

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

------
jordigh
Source at gitorious:

[https://gitorious.org/src-vcs/](https://gitorious.org/src-vcs/)

~~~
ten7
Oh the irony of hosting it on something other than SRC. SMH

~~~
fdej
[http://www.catb.org/~esr/src/FAQ.html#self-
hosting](http://www.catb.org/~esr/src/FAQ.html#self-hosting)

~~~
bshimmin
From that link:

> Is SRC used to develop itself? No. That would be silly.

From Git's Wikipedia page:

> The development of Git began on 3 April 2005. The project was announced on 6
> April, and became self-hosting as of 7 April.

~~~
owenmarshall
You're kinda missing the point: this project is designed around a single user
maintaining a linear history for a single file. Using it for a project would
be a weird impedance mismatch.

That's not to say I find SRC compelling... in the slightest. Just that you'd
never use SRC to track a project.

~~~
bshimmin
You're right, I was mostly just being snarky - but, that said, the source of
SRC (sigh - what a terrible name, as others have said) is, in fact, just one
Python file, so I suppose you could arguably use SRC for it.

I don't find it at all compelling either.

~~~
owenmarshall
Hah. I just looked at the src (heh) - you're right, one file. I take back my
argument.

If esr wants to fetishize a time when Real Programmers took patches over nntp
and applied them in rcs, then by god he should go all in and self host the
thing!

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

------
kazinator
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](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
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...

------
ansible
For this niche, I use vcsh:

[https://github.com/RichiH/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.

------
sparticvs
Sounds like someone misses DEC VMS's method of revision

~~~
GFK_of_xmaspast
I sort of do.

------
jarun
How about fossil?
[http://tuxdiary.com/2013/09/20/fossil/](http://tuxdiary.com/2013/09/20/fossil/)

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

------
coned88
What's wrong with RCS?

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

~~~
GFK_of_xmaspast
"a nice enough guy"

Nope:

[http://esr.ibiblio.org/?p=26](http://esr.ibiblio.org/?p=26)

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

~~~
pothibo
For those of you brave souls who downvote me. I'm wondering which part of my
statement you disagree with.

\- You think homosexual are pedophiles?

\- It's not important what he thinks about homosexuals. You're going to
support him by using his software.

If he had held the same hate speech about women in 2014, everyone would be
here talking how imbecile this guy is.

~~~
edwintorok
People can have different political, religious, etc. views than you, but why
should that influence whether you use his software or not?

Do you check the political views of all authors of each software before you
decide to use it? What if those views (or your own) change over time and you
disagree with them?

~~~
icebraining
(ESR aside) Why not? If I believe that someone's exposed views are harmful,
doesn't it make sense to avoid increasing his/her overall influence?

I mean, the fact that we're discussing ESR's views on pedophilia shows that
his influence in an unrelated area (software) increases the exposure of those
views. If he was just a nobody like me, would we be discussing his blog post
on Catholic priests? Not likely.

 _Do you check the political views of all authors of each software before you
decide to use it?_

I sure don't, but why does that mean one should actively ignore gained
knowledge?

~~~
edwintorok
First of all it would take too much time to find out all the authors of all
the software that I routinely use, and then keep up with what their current
views are on various topics.

But I think the main reason is that most software has more than one author,
and it would be unfair to judge the usefulness of that software based on the
(non-technical) views of just one of its authors.

Your reasoning would apply only for single-author software, and TBH I would
consider those pet-projects anyway, and I don't think the original author
would care much whether you use it or not.

Edit: about gained knowledge: I think you could apply this if you _compare_
multiple competing solutions, one deciding factor could be the author's
thoughts on various topics. Just like how a company's attitude towards various
topics might be influencing your purchasing decision: for example Nvidia
doesn't support open-source drivers, hence I don't buy Nvidia when choosing a
graphics card.

But again for me those are all technical reasons, I wouldn't factor an
author's/company's political views into that decision, unless it was something
really horrible.

~~~
icebraining
_Your reasoning would apply only for single-author software_

But doesn't that fit SRC itself?

 _But again for me those are all technical reasons, I wouldn 't factor an
author's/company's political views into that decision, unless it was something
really horrible._

Ah! But then you're not arguing whether it makes sense to factor the political
views in the decision - what you're actually arguing is that ESR's views are
not really horrible.

But since pothibo supposedly considers them really horrible, it makes sense
that (s)he would factor in those views, no?

~~~
edwintorok
Maybe, although I don't think I made technical decisions based on unrelated
events. The closest that comes to mind is as described here:
[https://news.ycombinator.com/item?id=8602582](https://news.ycombinator.com/item?id=8602582)
I did use ReiserFS in the past, and I _did_ switch to something else but the
reason was purely technical: XFS became quite good on a HDD, an ext4 very nice
on an SSD, and also there didn't seem to be much development done upstream
once the original author was gone.

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

