Comments for RCS vs. Git for quick versioning

[phinjensen]

Comments for https://www.endpointdev.com/blog/2009/12/rcs-vs-git-for-quick-versioning/ By Greg Sabino Mullane

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: Moritz
date: 2010-07-13T07:14:27-04:00

rcsdiff can pass options to the underlying diff command, which it invokes internally, for instance for a unified diff, you can use rcsdiff -u, for ed-scripts rcsdiff -e, for context-diffs rcsdiff -c. you can generate patches by rcsdiff -u foo.conf > foo.diff and have syntax hilighting for it using vim foo.diif ;)

Cheers

[phinjensen]

original author: Greg Sabino Mullane
date: 2010-07-13T09:38:47-04:00

Thanks for the tip Moritz, that's good to know.

[phinjensen]

original author: Anonymous
date: 2010-08-31T17:26:52-04:00

or do like I did and just write a simple script that can pull out any two versions of the file in question and send them to one of several gui diff/merge tools that are out there.

[phinjensen]

original author: Anonymous
date: 2011-12-01T10:58:17-05:00

A few notes:

• "On the other hand, Git requires [...] and the use of long, hard to type hexadecimal numbers". Not really, git has many ways to name commits, you can use partial sha (11a0 instead of 11a049bc80fe4a2f4584465fe13d8bb4ee479f23 as long as they are unambiguous), you can 'tag' any commit and use that tag as a name (example: '1.20'), you can even refer to commits relative to each other, the current one being HEAD: HEAD~3 = three commits ago, 1.20~2 = the 'grand-parent' of the commit that was tagged as '1.20', you can referer past commits (from any starting point) based on date: HEAD@{yesterday}, @{3 days ago}. You can refer commits even by their log message: HEAD:/text refers to the first (closest past commit) that contains 'text' in its commit log. I suggest reading http://schacon.github.com/git/gitrevisions.html

• Overall, git does not do 'versioning' at all. There can be multiple repositories, each with local tags. So, git doesn't care if both two users in thier repositories tag two different commits as '1.20'. Of course, users may agree that a certain repository is the main one, and tags there are the official revisions, but that's not something that git enforces.

[yarikk]

Nice write-up! Brings up lots of memories. Before times, I did use RCS extensively for many things: system configuration, shared scripts and tools etc.

I miss RCS for:

• Per-file history which you can drag along with the file, freely. That had own downsides, but it felt like lots of freedom. Modern version control just feel more constrained.
• Short, terse commands. UNIX style.

Peculiarities of RCS I don't miss:

• ci filename deleting the file. You've got to remember to supply -u or -l always. It should've been fixed ages ago.
• Locking on checkout. Always created unnecessary traction, so we always had rcs -U mode on our files.
• Sandbox checkouts must be on the same machine or have the version files on an NFS mount. No standard way to coalesce check-ins made to distributed copies of the version files.
• No handling for directory changes. No renames, deletions, recursion.

[chipschap]

Commenting years after the original posting, the write-up rings true, and there is a specific application for which RCS really shines.

I do a lot of writing and typically use Emacs org-mode. It enables me to have a single text file per writing project, including notes, research, etc., as well as the text itself. This is especially good for writing novel-length fiction.

RCS is perfect for writers. There is almost no setup and dead simple check-in and check-out. Writers often work alone, and the single-file model with Emacs org-mode suits RCS to a T.

Git with Magit on Emacs is very powerful and useful, but it's way, way too much for the work I'm doing. Of course, when I'm in say the 3rd revision of a 100,000 word novel, that ",v" file can get to be a few megabytes in size, but it's hardly a problem when combined with a sensible backup strategy (I back up both the active file and the ,v file after every work session, without fail---- but it's only two files to worry about).

New stuff is great but sometimes, so is old stuff like RCS.

[charles-stepp-imprivata]

KISS vs Teamwork. I REALLY like adding the rcs auto fill parts. A little script, addrcs, and then "!!addrcs" in vi(m). Boom. Too simple.

It is inconceivable that git doesn't have auto replace versioning. Certainly it must.

$ addrcs
# ----------------------------------------------------------------------
# $Header$
# ----------------------------------------------------------------------
# $Log$
# ----------------------------------------------------------------------

[chipschap]

It's good to see this very useful discussion continue, and I'll add one more comment of my own. Earlier I stated I use RCS (with emacs) for my writing projects, and I continue to do so.

RCS shines for:

1. Management of a single file. My novel files get pretty large, but everything is in one file, something made easy with emacs and org-mode.
2. Single-user projects. Writing, especially fiction, is usually a lonely occupation and I don't have to worry about merging multiple authors' changes.
3. Single-machine use. The ",v" repo resides on one machine. Multiple machines is really similar to (2) above but I have a way to manage this, see below.
4. Version control that is relatively simple. Mostly I want a record of changes and the ability to recover that deleted scene that I now think should go back in the story, or alternatively, that earlier version of a bash script which actually worked better than my new experimental one. So much easier than keeping multiple copies of files and trying to recall which is which.
5. Ease of use. You can learn to use RCS on emacs in five minutes.

Of course git and others are what you need for distributed, multi-user projects. No question RCS doesn't cut it for that.

As to the single machine limitation, for me that means one machine at a time. I have maybe 8 different devices and I use rsync (to a cloud service) to keep them all on the same page (pun intended). As long as I'm not writing the same novel on two different machines at once, and as long as I remember to up-sync when done and down-sync when starting, the method is extensible to an arbitrary number of machines. Okay, you have to learn to use rsync but it's once and done, and I suppose you could substitute one of the automated folder sync services instead, but I prefer the flexibile options of rsync (like another layer of versioned backups).

It's surprising, and pleasing, just how long RCS has been around and how it still retains relevance and utility. Even this discussion now spans five years!