Source control: mandatory or not
-
El Corazon wrote:
That is because you cannot imagine a one man shop with 100,000 line programs.
No I can't. I don't think anything but some of our in-house utilities is that small. Ahhh now you had to go and get all personal about it. :) I wasn't dissing you or anyone else, I just hate blind dogmatic thinking and I see more of it here than I see anywhere else when it comes to tools and methodology. I originally started out by stating that I thought source control was a waste of time and resources, dangerous and fragile and limited that to my own personal experience, needs, situation etc. I was flamed so heavily for uttering what seemed to many to be a heresy that I thought it was funny as I always do when I see programmers who are in an industry that is perhaps the most important to be flexible in your way of thinking being so dogmatic. So you see your entire statement above I agree with and was trying to illustrate but somehow you've flipped my argument on it's head. At least we're all getting a lot of finger excercise today! :)
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
John Cardinal wrote:
At least we're all getting a lot of finger excercise today!
yup, but I still think even if you don't need it, there are some who do. I have to branch and merge for contract obligations. If I branch for MDA and lock their version until after the mission, I have to merge it back in, even if I have done work for the Air Force or FCS or DFCS in the mean time. Or worse, all three. One man shop can operate as a team of 10 for 10 customers. the Utah range is here this week too, loving the new stuff, but asking for more. That is life in the middle of no where. I do not believe it is a waste of resources, and our track record shows it is true. I have out distanced every other 3D competitor in the market including the big guns, and including my own parent companies Lockheed Martin and others. CSC brags about us because they had no such technology, now they do, and suddenly they are side by side with the largest names in 3D. The question is all about how you use it, and what cautions you take. I would never tell anyone to trust source control anymore than you would tell your employees to make one copy of their work (I hope). But I will use the source control as I do the compiler, profiler, and IDE. It is a tool, it has a purpose, and when used for the entire purpose, not just source backups, it far outdistances a simple backup. No more diffs and windiffs except for regression comparisons, or new bug serearchs. When you have a bug and 5 releases ago you did not for that some function. What have you changed. You pull out the disks, restore the backups to a new directory, start walking through the diffs. I pull up the history, diff-online, search for the error and usually find it before you could get the source backup restored. But it really is a difference in need. If I told the US military to stuff themselves because we can't change now to support someone else, I wouldn't have a job long. They say jump, you ask how high. The moon is coming in soon, right now I am trying for the fourth dimension. ;) But since it does come down to need, you may not need it, others will. leave it at that.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
Using a reliable code management system is clearly superior, but that doesn't automatically make it mandatory. I've worked in large teams that did, and large teams that, ummm... used their own "system" (:cough: bogus :cough:). Currently I'm a team of one and my current practice is to archive to a CD every Friday, which I'd consider a bare minimum. I don't feel like learning VSS, I've only ever heard bad things about it.
-
My assertion was that it's not mandatory and is in fact harmful for a small shop with just a few programmers (3 or less). A lot of this stuff has been foisted on to programmers by corporate types who are trying to turn software development into a factory process like stamping out microwave ovens. That's fine if you work in a factory but I have a small shop and we are craftsmen not assembly line workers and nearly any modern software development methodology that is the buzzword of the day simply makes no sense in a smaller craftsman software development shop. I reject agile development, I reject source control, I reject gannt charts, I reject UML diagramming, I reject a lot of things because any sane, logical examination shows them to be unnecessary overcomplication for my situation. Those are all tools to deal with mashing together a large number of programmers and trying to make them act as one entity. That's fine for what it's designed for but far too often I see people asking here about these things for their one man projects and shops and we all have to be careful to realize that one size does not in fact fit all and everyone's perspective is based on their situation that they are in. You simply can not say with any degree of accuracy that source control is always mandatory. I've been *extremely* sucessful doing what I do the way I do it and my perspective is always from the point of view of a craftsman not a cubicle jockey (not that there's anything wrong with that ;) ). If every poster here could have some sort of icon that represents the situation they are in, size of shop, type of software etc then discussions would be much more productive because you could look and balance someone's assertion with their situation and judge it appropriately.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
Oh, shucks, i missed a good argument. :rolleyes:
John Cardinal wrote:
I've been *extremely* sucessful doing what I do the way I do it and my perspective is always from the point of view of a craftsman not a cubicle jockey
Sure. Source control - especially with the largely-inane clients available for most systems - is a lot of overhead. And whether that overhead is necessary does depend a lot on the skill and discipline of those involved. That said... while perhaps it's not accurate to deem it "mandatory", that just puts it in the same category as things like Intellisense, build systems (including makefiles) and IDEs, none of which are strictly required and all of which impose some sort of overhead. Those of us who use them do so because we've found them useful in reducing overhead in some other way - whether that's the manual effort involved in resolving build dependencies or in merging code changes. I worked for many, many years with my own set of scripts and procedures for managing change sets, even when source control was required. Only in the past few years have systems like Subversion proved themselves robust and convenient enough that i've been able to use them for day-to-day management of code changes. And i could still do without it... but i wouldn't want to. A useful tool is one that has a clear benefit to offer in exchange for its cost - for more and more of us, source control has become such a tool. Obviously, it hasn't reached that threshold for you yet. ;)
John Cardinal wrote:
If every poster here could have some sort of icon that represents the situation they are in, size of shop, type of software etc then discussions would be much more productive because you could look and balance someone's assertion with their situation and judge it appropriately.
Yeah, yeah. And if each post had a web-cam slideshow of the person as they wrote, sarcasm would be easier to detect. Maybe. :rolleyes:
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
Using a reliable code management system is clearly superior, but that doesn't automatically make it mandatory. I've worked in large teams that did, and large teams that, ummm... used their own "system" (:cough: bogus :cough:). Currently I'm a team of one and my current practice is to archive to a CD every Friday, which I'd consider a bare minimum. I don't feel like learning VSS, I've only ever heard bad things about it.
PIEBALDconsult wrote:
Using a reliable code management system is clearly superior, but that doesn't automatically make it mandatory.
Right there is the quintessential answer to the question of this thread. It can be a great tool, there are many reasons to use it, and few not to use it. But is it mandatory? After double checking with Webster, clearly mandatory is not the right word to describe it. I voted 5 for this one, but I'm sure that won't last long once the sheep come around here. Regards, BDF
-
John Cardinal wrote:
At least we're all getting a lot of finger excercise today!
yup, but I still think even if you don't need it, there are some who do. I have to branch and merge for contract obligations. If I branch for MDA and lock their version until after the mission, I have to merge it back in, even if I have done work for the Air Force or FCS or DFCS in the mean time. Or worse, all three. One man shop can operate as a team of 10 for 10 customers. the Utah range is here this week too, loving the new stuff, but asking for more. That is life in the middle of no where. I do not believe it is a waste of resources, and our track record shows it is true. I have out distanced every other 3D competitor in the market including the big guns, and including my own parent companies Lockheed Martin and others. CSC brags about us because they had no such technology, now they do, and suddenly they are side by side with the largest names in 3D. The question is all about how you use it, and what cautions you take. I would never tell anyone to trust source control anymore than you would tell your employees to make one copy of their work (I hope). But I will use the source control as I do the compiler, profiler, and IDE. It is a tool, it has a purpose, and when used for the entire purpose, not just source backups, it far outdistances a simple backup. No more diffs and windiffs except for regression comparisons, or new bug serearchs. When you have a bug and 5 releases ago you did not for that some function. What have you changed. You pull out the disks, restore the backups to a new directory, start walking through the diffs. I pull up the history, diff-online, search for the error and usually find it before you could get the source backup restored. But it really is a difference in need. If I told the US military to stuff themselves because we can't change now to support someone else, I wouldn't have a job long. They say jump, you ask how high. The moon is coming in soon, right now I am trying for the fourth dimension. ;) But since it does come down to need, you may not need it, others will. leave it at that.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
It is a tool, it has a purpose
Yup and you know me well enough to know by now I've said something similar a thousand times about other technology. Cmon, you just know I'm grinning away when I'm typing some of this stuff. ;)
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
Oh, shucks, i missed a good argument. :rolleyes:
John Cardinal wrote:
I've been *extremely* sucessful doing what I do the way I do it and my perspective is always from the point of view of a craftsman not a cubicle jockey
Sure. Source control - especially with the largely-inane clients available for most systems - is a lot of overhead. And whether that overhead is necessary does depend a lot on the skill and discipline of those involved. That said... while perhaps it's not accurate to deem it "mandatory", that just puts it in the same category as things like Intellisense, build systems (including makefiles) and IDEs, none of which are strictly required and all of which impose some sort of overhead. Those of us who use them do so because we've found them useful in reducing overhead in some other way - whether that's the manual effort involved in resolving build dependencies or in merging code changes. I worked for many, many years with my own set of scripts and procedures for managing change sets, even when source control was required. Only in the past few years have systems like Subversion proved themselves robust and convenient enough that i've been able to use them for day-to-day management of code changes. And i could still do without it... but i wouldn't want to. A useful tool is one that has a clear benefit to offer in exchange for its cost - for more and more of us, source control has become such a tool. Obviously, it hasn't reached that threshold for you yet. ;)
John Cardinal wrote:
If every poster here could have some sort of icon that represents the situation they are in, size of shop, type of software etc then discussions would be much more productive because you could look and balance someone's assertion with their situation and judge it appropriately.
Yeah, yeah. And if each post had a web-cam slideshow of the person as they wrote, sarcasm would be easier to detect. Maybe. :rolleyes:
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Shog9 wrote:
sarcasm would be easier to detect
Maybe if we had a "dripping with sarcasm" message type icon.....
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
-
El Corazon wrote:
It is a tool, it has a purpose
Yup and you know me well enough to know by now I've said something similar a thousand times about other technology. Cmon, you just know I'm grinning away when I'm typing some of this stuff. ;)
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
John Cardinal wrote:
Yup and you know me well enough to know by now I've said something similar a thousand times about other technology. Cmon, you just know I'm grinning away when I'm typing some of this stuff.
yup, and laughing at every 1 because you managed to get the room riled up to a fury pitch! Every place has a trouble maker. ;) John, when the Nurse slapped you to make you start breathing, I bet you slapped her right back or at very least vomitted something disgusting on her and smiled as big as you are right now. just be glad you don't need the branch merge, because without a source control, your customers would have you running powers of two times the work for every customer change. branch merge barely keeps it under control.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
John Cardinal wrote:
Yup and you know me well enough to know by now I've said something similar a thousand times about other technology. Cmon, you just know I'm grinning away when I'm typing some of this stuff.
yup, and laughing at every 1 because you managed to get the room riled up to a fury pitch! Every place has a trouble maker. ;) John, when the Nurse slapped you to make you start breathing, I bet you slapped her right back or at very least vomitted something disgusting on her and smiled as big as you are right now. just be glad you don't need the branch merge, because without a source control, your customers would have you running powers of two times the work for every customer change. branch merge barely keeps it under control.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
Every place has a trouble maker.
Hey I don't make trouble I just question assumptions. :)
El Corazon wrote:
just be glad you don't need the branch merge
I used to write custom software for different customers in the oil and gas and related industries and I know intimately the work required for that kind of stuff and it's precisely why we only make commercial software now and when anyone asks us if we can customize it for them we say sure for 500,000 dollars minimum we can look at doing that for you. :) The only way to make serious money in this business is to write once, sell as many times as possible.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
My assertion was that it's not mandatory and is in fact harmful for a small shop with just a few programmers (3 or less). A lot of this stuff has been foisted on to programmers by corporate types who are trying to turn software development into a factory process like stamping out microwave ovens. That's fine if you work in a factory but I have a small shop and we are craftsmen not assembly line workers and nearly any modern software development methodology that is the buzzword of the day simply makes no sense in a smaller craftsman software development shop. I reject agile development, I reject source control, I reject gannt charts, I reject UML diagramming, I reject a lot of things because any sane, logical examination shows them to be unnecessary overcomplication for my situation. Those are all tools to deal with mashing together a large number of programmers and trying to make them act as one entity. That's fine for what it's designed for but far too often I see people asking here about these things for their one man projects and shops and we all have to be careful to realize that one size does not in fact fit all and everyone's perspective is based on their situation that they are in. You simply can not say with any degree of accuracy that source control is always mandatory. I've been *extremely* sucessful doing what I do the way I do it and my perspective is always from the point of view of a craftsman not a cubicle jockey (not that there's anything wrong with that ;) ). If every poster here could have some sort of icon that represents the situation they are in, size of shop, type of software etc then discussions would be much more productive because you could look and balance someone's assertion with their situation and judge it appropriately.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
Hrmmm... While I don't agree that source control SOFTWARE is mandatory, some kind of source control PROCESS is, in my opinion. Without it, you cannot adequately manage multiple developers (even 2) working on the same project (unless they never touch each others code) and you're kind of screwed if you need to maintain multiple releases of the same software. Source control software comes in many flavors, from the simple to the insanely complex. It makes little sense to do this by hand when there is likely a tool out there that will fit whatever process you want to use. Having said that, I can't imagine how source control can be "harmful". Can you explain that?
-- Where are we going? And why am I in this handbasket?
-
Hrmmm... While I don't agree that source control SOFTWARE is mandatory, some kind of source control PROCESS is, in my opinion. Without it, you cannot adequately manage multiple developers (even 2) working on the same project (unless they never touch each others code) and you're kind of screwed if you need to maintain multiple releases of the same software. Source control software comes in many flavors, from the simple to the insanely complex. It makes little sense to do this by hand when there is likely a tool out there that will fit whatever process you want to use. Having said that, I can't imagine how source control can be "harmful". Can you explain that?
-- Where are we going? And why am I in this handbasket?
We never have more than one developer working on the same area of code at the same time, we do not maintain multiple releases as we make commercial "off the shelf software" and avoid multiple releases like the plague for many reasons chiefly you can go broke trying to please specific customers. Multiple releases go against everything that makes you money as a software company. Write *once* sell many times makes you money and ensures happy customers because of all the time and complexity saved that can be plowed directly into the single trunk project. We do have a source control process of a kind, I would never refer to it as that, more of a kick ass backup system consisting of nothing more than batch files, command line winzip, cd burner and zip tape drive with 10 tape *off site* rotation system. I can if I ever need to restore any one of 30 copies of active projects from any period within the last decade to as recently as the last time I got up from my computer during a work day, it's never been required but if it was I can do it. A source control system is dangerous in that your code is in a much more fragile place, you tend to start relying on it, there is a post here at minimum once a month about some source control software disaster or problem and it seems to take up a lot of developers time, time best spent writing code, not frigging around with tools that are completely unnecessary. Of course as I've said and will say again because some people are too thick apparently to get it (not you, others) I am speaking for my own situation with my own company only. What is appropriate for us may ver well not be appropriate for others so if anyone disagrees then I welcome them to set up an identical company, write identical software, do it for a decade sucessfully and come back and show me where my opinion is wrong. Sorry to rant but I've had to deal with a lot of narrow minded dogmatic people on this an other issues who can't seem to understand that in fact we aren't all dead eyed corporate cogs working in "campuses" sitting in cubicle farms all day in an assembly line software factory. :)
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
Some form of backup system seems like a wise move. Now, Source Control do have it's benefits but occasionally it can be overkill. In my case they just sits there and takes up space on the drives/servers -- I've needed to go back and check twice:-> in the last 25 years. Once was changes done more than three years ago (use check-in comment and labels), once was just a month or so old code but a massive amount of changes (took over a resource management system... written in VB6:omg:... No, I do not want to talk about it, the wounds are to fresh). Conclusion -- Mandatory (some form of...). You never know when it would have had been nice to have:-D
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
I'd say that procedural/operational source control is mandatory, in any case. This does not necessarily imply that is implemented by means of functional/technical source control. For small teams, this can be an overkill. In my case, working in a 100+ programmers environment with multiple projects, we're on VSTS+TFS+clustered mirroring. The full-fledged MS stack is extremely beneficial in a large environment, with branching of versions, shared checkins, merging, shelving, and numerous dependencies to be guarded (in spite of component-based development ;-) However, it does mean having a full-time configuration manager and the technical facilities and personnel in place to be able to do that. Not an option for relatively small environments. The whole shabang of course is not by any means a guarantee for productivity and quality. Smaller teams are usually more effective and efficient on these counts ;-) Regards, Arjan Keene
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
I would never work without it - even for solo projects. I've played the "zipfile game" before, and it's dangerous to say the least. Never again.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Again, we are a very small shop and I couched all my statements within that frame of reference. I simply don't see an advantage for a shop with 3 or less people in it. We are all working on completely different areas / aspects of the project at the time there is zero chance another person is going to touch our own area of responsibility. I don't have any experience working with a large team of programmers and I'm always careful to scope what I say within that frame but sadly that seems to have gone unnoticed by most everyone. If a 1 man shop developer tells me they need a source control system I tell them they are full of shit and wasting time playing with tools that a simple batch file and archiver could more simply and easily acheive. At the end of the day I want to be writing code, not farting around with unnecessary steps. Perhaps working in a small shop that I am entirely responsible and paying for I have a clearer understanding of what's truly important and what is just dragging you down. We work on a razor's edge to be able to do the size of projects we do with the limited resources we have and that is the kind of situation that hones my processes over the years to a very fine point.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
John Cardinal wrote:
If a 1 man shop developer tells me they need a source control system I tell them they are full of sh*t and wasting time playing with tools that a simple batch file and archiver could more simply and easily acheive.
That's a pretty daft statement, if you ask me. I do 90% of the development for Riverblade, so we're almost in that category. Nevertheless, both Beth and I consider SCC (even VSS, for all its failings) absolutely essential, and I regularly spawn new repositories or branches for new developments - even if I'm going to be the only one working on it. I certainly don't consider myself "full of shit" for wanting to use tools which allow us to check in incremental changes regularly and be able to instantly see what's happened to a file or project over its entire lifetime without opening several dozen zipfiles... For the record, we work pretty close to the wire too, so I don't tolerate slack any more than you do. VSS is free (via MSDN) and easy to administer for a codebase of our size. The risks are low for us (I know the thing backwards, and an automated backup goes out everynight), and the benefits are high. Why make life difficult, after all?
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
It depends on the project and team. One person trying to figure out an API does not need revision control. Large teams need it at least to keep changes straight between developers. I make it a habit to check (compare) my changes prior to commit to ensure that I have not left something in the code (like a System.Out), and that I have dealt with any TODOs or notes I added while making the change. Other developers may have different approaches they use for this. In general I would say it is a good idea.
Tanks for your support
Pat O
Blog_ _ _
/*\== /*\== /*\==
<ooo> <ooo> <ooo> -
Optional if you have a project wiht one developer, and it zips in five seconds or less. Multiple people working on the same code base? Hacking features for 2.0 during the beta phase for 1.0? Automated clean builds? Who the phuket added this line of crap? Source Control. (ok, ok, I was)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistI do alot of work by myself, but I use source control. There are a number of free source control systems. I currently use Sourcegear vault, which is free for single users. http://www.sourcegear.com/faq.html[^] Quote: "Yes. Both Vault and Fortress are free of cost when used by a single user." Doing a diff on previous version to the current version is more difficult with just a collection of zip files. However, I also burn all my source code directly to CD or DVD periodically, along with the repository backups.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
Absolutely mandatory - even for a one-man shop. I can't even imagine a professional developer questioning it.
Nemanja Trifunovic wrote:
Absolutely mandatory - even for a one-man shop.
Source code backup process - yes, mandatory. Actual Source control software - absolutely not. I am a professional developer, have been since pre PC days. I do not have Source Control. I do have regular backups of source files. I was in charge of the source control and documentation library for a large company. Developers were different people than maintainers. I am well versed in what it does and what it does not do for the organization, where and why it's needed. It is absolutely NOT necessary in a small shop. I don't need the headaches, overhead, nor wasted time. We don't support multiple versions of the same product. Copying working directories before making major changes is sufficient. Backing up live directories to Zip files and then to CD and hard Disk is absolutely sufficient. Again, small shop. No two people work on the same thing. To have others foist their methodologies on my operations because they don't have the structure, knowledge nor experience is just dumb. :mad: I can take any backup, unzip it onto a development machine, and have 100% of what I need to duplicate the object code. I need nothing else - no intermediate files, modified make files, previous versions, later versions, nothing. I don't need a separate Source Control Server to maintain. Simple, sweet, does the job 100%. :) Now, if someone can explain to me why this does not work, I'll listen. But my (extensive) experience has proven that it works just fine, thank you very much.
Gary
-
Following this discussion[^] with Mr Cardinal, it seems there are very contrasted opinions on the subject. What do CPians think about it? Mandatory when your job is producing code or not?
Heresy. I believe in the power of source control, and I recommend smiting the admin not backing up the repository offsite. There are dozens of reasons to use source control from disaster recovery to blaming the right coder. Because there are so many free, solid, and integrated version control systems, there is no excuse for not using them.
Cheers, Daaron
-
I would never work without it - even for solo projects. I've played the "zipfile game" before, and it's dangerous to say the least. Never again.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
I've played the "zipfile game" before, and it's dangerous to say the least
Not as dangerous as playing the 'Hmmm - the VMS filesystem has version numbers - let's use that for source control' game...'cause then your quota will start to run low, you'll do a casual recursive
PURGEand all those previous versions will disappear, as if by magic. And yes, this is a tale from experience - not mine, thankfully - I used CMS, the VMS equivalent of RCS.