rbenv

Simple Ruby Version Management: rbenv

rbenv lets you easily switch between multiple versions of Ruby. It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.

rbenv does…

• Let you change the global Ruby version on a per-user basis.
• Provide support for per-project Ruby versions.
• Allow you to override the Ruby version with an environment variable.

In contrast with rvm, rbenv does not…

• Need to be loaded into your shell. Instead, rbenv's shim approach works by adding a directory to your $PATH.
• Override shell commands like cd. That's dangerous and error-prone.
• Have a configuration file. There's nothing to configure except which version of Ruby you want to use.
• Install Ruby. You can build and install Ruby yourself, or use ruby-build to automate the process.
• Manage gemsets. Bundler is a better way to manage application dependencies. If you have projects that are not yet using Bundler you can install therbenv-gemset plugin.
• Require changes to Ruby libraries for compatibility. The simplicity of rbenv means as long as it's in your $PATH, nothing else needs to know about it.
• Prompt you with warnings when you switch to a project. Instead of executing arbitrary code, rbenv reads just the version name from each project. There's nothing to "trust."

Table of Contents

• 1 How It Works
• 2 Installation
• 3 Usage
  • 3.1 global
  • 3.2 local
  • 3.3 versions
  • 3.4 version
  • 3.5 rehash
• 4 Contributing
  • 4.1 License

vestal_versions for Rails 3

acts_as_versioned by technoweenie was a great start, but it failed to keep up with ActiveRecord’s introduction of dirty objects in version 2.1. Additionally, each versioned model needs its own versions table that duplicates most of the original table’s columns. The versions table is then populated with records that often duplicate most of the original record’s attributes. All in all, not very DRY.

vestal_versions requires only one versions table (polymorphically associated with its parent models) and no changes whatsoever to existing tables. But it goes one step DRYer by storing a serialized hash of only the models’ changes. Think modern version control systems. By traversing the record of changes, the models can be reverted to any point in time.

https://github.com/laserlemon/vestal_versions
http://railscasts.com/episodes/177-model-versioning

Amp

About Amp

Amp is a general-purpose version-control system. It currently implements Mercurial, and we hope to support git, bazaar, svn, cvs, and darcs in the future. Why? Well, that leads us to the question: "Why Amp?"

Amp is NOT:

Amp does not define a repository format, and most likely never will.

Then why make a VCS?

Amp exists because there's plenty of excellent repository formats out there, but none of them are truly good software. We chose Mercurial as our first VCS to implement because it comes closest to what we feel is a solid user experience, and that's what we're building upon.

Amp exists to make VCS work for you. Want to add your own commands? Write a few lines of code. Want to use git's commands on a Mercurial repository, switches and all? Amp is working on it. Our goal is to produce a piece of software that lets you forget that you're working on git project one moment and a Mercurial project the next.

Amp's Features

• Workflows - customizable command sets (e.g. git's commands, svn's commands)
• Commands - work with your VCS on your terms
• Ampfiles - tweak amp's settings for a specific repository with one file
• Want more features? Help develop Amp! We've got a lot planned!

http://amp.carboni.ca/