Open phinjensen opened 6 years ago
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
original author: Greg Sabino Mullane
date: 2010-07-13T09:38:47-04:00
Thanks for the tip Moritz, that's good to know.
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.
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.
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:
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.rcs -U
mode on our files.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.
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$
# ----------------------------------------------------------------------
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:
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!
Comments for https://www.endpointdev.com/blog/2009/12/rcs-vs-git-for-quick-versioning/ By Greg Sabino Mullane
To enter a comment: