I'll take your word for it. For me, it mostly saves me a bunch of time.
Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use.
Double Edit: "a bunch" is probably an overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.
This is kind of a classic "fast, correct - choose one" debate. If saving time is more important, perhaps you should use RVM in production, if correctness is more important, you probably shouldn't. It comes down to how expensive your mistakes are.
If you only have one server and can script most of the install process it's not a problem. When you have more than one server, rvm is not going to save you time.
I have my gripes with RVM, but this isn't one of them. I work on a project for provisioning and deploying EC2 servers. It's a capistrano plugin called rubber.
In any event, the immediate benefit is we can provide a tool that lets our users set up whatever Ruby they want to use, as we shouldn't be forcing that on them. Moreover, it makes it dead simple to deploy different Rubies out to different parts of the cluster, since everything is role-based. That's far from the common use case -- most people use the same Ruby everywhere. But if you have more complex needs, RVM affords a lot.
Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use.
Double Edit: "a bunch" is probably an overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.