GNU RCS 5.9.2 | Hacker News Reader

GNU RCS 5.9.2

lists.gnu.org

38 pointslelf17 comments

I still use RCS occasionally for versioning single files, although the speed and ease of initialization of Git make it not so useful these days. Incidentally, having maintained RCS history for a large file that made it up to 1.1677, I discovered that GNU RCS is very inefficient at applying the reverse line-based diffs in order to retrieve an old revision - rcs takes 27 seconds to retrieve 1.1 while my small Python implementation takes 0.5 seconds. I guess it probably keeps in-memory data in a contiguous buffer rather than an array of lines?

Can you post your ,v file somewhere? I'd like to try to replicate your experiment, using my rcs(1) and cvs(1).

While I'm impressed that your Python script is quick, I'm not sure that Python is ever "small" compared to any POSIX-like UNIX userland utility. An accurate perspective of the size of any "Python implementation" would account for (a) all the files you need to install on top of a POSIX-like UNIX userland in order to get Python to run and to run your script and (b) the fact that the OS Torvalds would have used if not for the AT&T lawsuit, namely BSD, does not include Python in the base install. If Python were truly "small", I'd consider it for use in embedded systems.

for old legacy systems, keeping /etc/ in RC is (and has been) a massive godsend.

Its nice to see a rarely used bit of software from 31 years ago still being maintained.

Nowadays I sometimes create a git repo in my /etc directory

I use etckeeper, which is basically the same thing except with some nice hooks like auto-commit on apt-get install.

And fixes the permissions. With /etc in git it becomes world-readable.

A script that gets the current permissions for every file/dir and emits a chmod command for each one is pretty handy.

If you find yourself versioning single files, and still want to use Git, you may want to check out "Zit, the Git-based single file content tracker".

https://github.com/Oblomov/zit

I use it extensively for any files I touch that I do not share with anyone else, especially configuration files. Comes included in NetBSD, so no need to install anything else.

We had to use RCS for university projects and submit the versioned files. It has many shortcomings but the simplicity of it is nice for some purposes.

People still use RCS?

Why take a car to the neighbourhood store when a fit-for-purpose bike would work just as well, while being free of all the complexities that a car has?

because it actually isn't helping your health or the environment to use RCS, and actually isn't more complex to do with another tool.

It's handy if you want a quick and simple way to preserve the history of edits for a single file, for example. So instead of a .bak file you can have an RCS file.

You could also have a DVCS repository just tracking this specific file.

I don't think you can have e.g. two files in the same directory tracked by separate git repos.

(Obviously there are workarounds like putting each in a directory by themselves, or maybe you just don't care if you happen to keep both in the same repo. Or you can use RCS.)

That seems like overkill.

See, most of the time I do "vim foo" to modify a file. But sometimes, on rare occasions, "echo bla > foo" seems to be a reasonable way to modify that file.

That said, most of the files I've used that on were in /etc, so since etckeeper arrived I've pretty much stopped using RCS. But before I knew about etckeeper, it was nice.

Reply on news.ycombinator.com