GNU RCS 5.9.1(lists.gnu.org)
lists.gnu.org
GNU RCS 5.9.1
http://lists.gnu.org/archive/html/info-gnu/2013-10/msg00001.html
29 comments
People may have information stored under RCS that they still want to access. It doesn't look like there's a lot of work being done to add new features, but having the ability to run RCS on new machines seems like it's a good hedge against data loss.
We're not using RCS, but we use GNU CSSC for an old SCCS codebase.
Many people here are keyed into 'new hotness' startup projects. But there are a lot of us out here maintaining 20+ year old codebases for products in maintenance/support mode only. Migrating them to modern version control is a tough sell. CSSC in particular lets me at least host the code on something modern.
Many people here are keyed into 'new hotness' startup projects. But there are a lot of us out here maintaining 20+ year old codebases for products in maintenance/support mode only. Migrating them to modern version control is a tough sell. CSSC in particular lets me at least host the code on something modern.
> So much for dogfooding...
It's not maintained by start-up people or MBAs so they don't have to handicap themselves in a world of trite buzzwords. Also, it's still maintained because people still use it. Figured that would be obvious.
It's not maintained by start-up people or MBAs so they don't have to handicap themselves in a world of trite buzzwords. Also, it's still maintained because people still use it. Figured that would be obvious.
If you want to version control a single file locally with no fuss (exactly one file,v file for storing changesets), I could still see it being handy.
It seems it has a maintainer that is very inclusive and accepts all portability fixes. Which is nice enough; many newer open source products are more like fireflies.
It seems it has a maintainer that is very inclusive and accepts all portability fixes. Which is nice enough; many newer open source products are more like fireflies.
I worked at an agency around 2000-2005 that used RCS to keep files like httpd.conf under source control. Not a great solution, but there were no free "configuration management" tools then, and it was a pretty unrestricted place, with developers and sysadmins sharing access to production systems. It's not what I'd do today, but it was better than nothing and gave them some safety without costing much in process.
One of my previous employers still uses CVS to version and deploy configuration. One reason why git is not an option is the simple fact that you can't check out subdirectories in git.
If one were using git, why would one need to check out a directory?
I have no objection to people using the tools they prefer, but they should be honest with themselves. The barrier to using git while working in a particular directory lies in changing one's VCS habits, not in a deficiency in git.
I have no objection to people using the tools they prefer, but they should be honest with themselves. The barrier to using git while working in a particular directory lies in changing one's VCS habits, not in a deficiency in git.
RCS is still used at my work. Some of its features (or omission of features) work well with our shared file system, and we often need to keep only one or two files in a directory under version control.
I ran into an RCS project of my own, just 2 days ago. There are code repositories out there older than git that are still important.
Adding to what others said, someone I know is planning to use this as a starting point for understanding version control systems. The reason stated was it's simplicity.
For distributed SCM, I've got enjoyment out of darcs documentation over the years (ie: http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theor...), and fossil (http://www.fossil-scm.org/index.html/doc/tip/www/permutedind..., specifically http://www.fossil-scm.org/index.html/doc/tip/www/tech_overvi..., http://www.fossil-scm.org/index.html/doc/tip/www/concepts.wi..., http://www.fossil-scm.org/index.html/doc/tip/www/fileformat...., etc)
git / RCS serve very different purposes.
RCS is a pretty excellent tool when you have a single file (like httpd.conf, hosts, a zone file) that you want to manage on a server. 80%+ sysadmins know how to ci/co and use rcs in that context. Likely less than 10% of sysadmins would grok the use of git in that context.
Also - does git even have the concept of "check out with lock, check in free lock, etc?"
RCS is a pretty excellent tool when you have a single file (like httpd.conf, hosts, a zone file) that you want to manage on a server. 80%+ sysadmins know how to ci/co and use rcs in that context. Likely less than 10% of sysadmins would grok the use of git in that context.
Also - does git even have the concept of "check out with lock, check in free lock, etc?"
>80%+ sysadmins know how to ci/co and use rcs in that context. Likely less than 10% of sysadmins would grok the use of git in that context.
Citation needed, because my experience is the exact opposite.
Citation needed, because my experience is the exact opposite.
Git was released in 2005. I will bet you a dollar that about 80% of the sysadmins in the world have been working with some kind of revision control since before 2005. It follows that they would have been familiar with something other than the Git model. Combine this with the laughable idea that not every sysadmin knows git, and the parent statement makes sense.
Also, your experience is probably not exactly the same as 80% of sysadmins. But I don't have a citation for that.
Also, your experience is probably not exactly the same as 80% of sysadmins. But I don't have a citation for that.
"some kind of revision control" =/= rcs, and eight years is quite a while. I'd happily bet that more sysadmins know git than rcs if you find a measurement.
While many sysadmins have heard of git, I've never run into one who has ever used it for anything more than just experimenting to learn the tool.
For server based control, it's mostly CVS, and, more recently (last 10 years or so) subversion.
For local file control it's all rcs .
For server based control, it's mostly CVS, and, more recently (last 10 years or so) subversion.
For local file control it's all rcs .
3-5 years ago what I saw was some CVS, some subversion. Nowadays it's some subversion, some git, maybe a bit of CVS hanging around. I had literally never heard of any sysadmins (or in fact anyone except one aging college professor) still using rcs prior to this thread.
If you've used Subversion, you've used CVS. If you've used CVS, you've used RCS. My whole point was that your average sysadmin is familiar with an RCS model, versus the Git model, which is incredibly different and a huge learning curve over older tools.
There are a lot of sysadmins out there. Most of them are older than 25, and most of them do not work in Silicon Valley. They work on all kinds of systems, for all kinds of companies. Any company that's been in operation for more than 10 years has files managed by CVS, or RCS if they've been around longer. They probably also use other tools and systems you've never heard of.
But that's OK. Today you'll get hired to manage new systems with new tools. In years to come, somebody will tell you how nobody uses SVN or Git anymore, and they've never heard of anyone that does.
There are a lot of sysadmins out there. Most of them are older than 25, and most of them do not work in Silicon Valley. They work on all kinds of systems, for all kinds of companies. Any company that's been in operation for more than 10 years has files managed by CVS, or RCS if they've been around longer. They probably also use other tools and systems you've never heard of.
But that's OK. Today you'll get hired to manage new systems with new tools. In years to come, somebody will tell you how nobody uses SVN or Git anymore, and they've never heard of anyone that does.
That would explain it - you've probably been working with sysadmins who've been doing their job for less than 10 years. Any Unix sysadmin with more than 10 years experience knows rcs very well. You typically see subversion where there is a server involved in version control.
It's what I learned in College, saw again at Netscape, again at Loudcloud/Opsware (though, for source control of code, they used Clearcase of all things. Shudder.) - always for the purpose of managing a single file. Once there was more than one file, something else was typically used.
It's what I learned in College, saw again at Netscape, again at Loudcloud/Opsware (though, for source control of code, they used Clearcase of all things. Shudder.) - always for the purpose of managing a single file. Once there was more than one file, something else was typically used.
There have been attempts to address git's shortcomings with respect to independent revision control of a single file: There is the "zit" project at
http://git.oblomov.eu/zit
...although it wasn't ideal for me, and it doesn't look like it's been updated in a while. E.g., these days that should be on GitHub!
RCS really fits well with the use-case of /etc configuration files. It's a pity that Git doesn't function very well for that particular case.
http://git.oblomov.eu/zit
...although it wasn't ideal for me, and it doesn't look like it's been updated in a while. E.g., these days that should be on GitHub!
RCS really fits well with the use-case of /etc configuration files. It's a pity that Git doesn't function very well for that particular case.
I've been using etckeeper on all my machines for a while. It is a wrapper around git + some hook scripts to preserve file permissions and the existence of empty directories. I can't imagine going back to an unmanaged /etc directory now.
I believe Perforce still uses RCS under the covers.
RCS format not RCS and only when text files are used.
Yup, thanks for the clarification.
As an aside, I discovered the RCS bit after our perforce server had some trouble and started throwing back some error messages with 'RCS' and ',v' in them. :)
I'm not much of a Perforce expert, so I had not noted that the docs mention RCS.
As an aside, I discovered the RCS bit after our perforce server had some trouble and started throwing back some error messages with 'RCS' and ',v' in them. :)
I'm not much of a Perforce expert, so I had not noted that the docs mention RCS.
It is a dogfood eating cat. :-)
In most other VCSs, revision numbers apply to the entire repository. In RCS and CVS, they apply to single files, which can be more convenient if you're maintaining a collection of files that are largely independent of each other.
[deleted]
I'm using rcs for quick and dirty versioning of my config files. Very easy to do. Clean. Zero config. No dependencies. No fluff.
http://git.savannah.gnu.org/cgit/rcs.git/?h=p
So much for dogfooding...