Ответ 1

Для стандартных проектов

Проверьте .ruby-version, если ваш проект зависит от рубина, например ruby-2.0.0. Проверьте .ruby-gemset только в том случае, если ваша команда согласилась на это. Добавьте .rvmrc в .gitignore, чтобы каждый мог переопределить параметры .ruby-* файлов с помощью .rvmrc.

Для драгоценных камней

Зайдите в .ruby-version с помощью ruby-1.8.7, только если ваш проект по-прежнему нацелен на ruby ​​1.8.7, в противном случае проверьте его, только если ваш камень требует его. Не проверяйте .ruby-gemset.

Ответ 2

Проверка в .rvmrc, .ruby-version или .ruby-gemset?

ДЛЯ:

• У вашего проекта разные отрасли (скажем, проект RubyGems, поддерживающий версии Ruby 1.8, 1.9 и 2.0). Лучше проверить этот файл, чтобы ваши разработчики не должны продолжать редактировать эти файлы при переключении ветвей. То же самое не относится к приложению, хотя, в основном, вы работаете только с одной версией Ruby.

• В том же случае, что и выше, но скажите, что вы используете CI-сервер (например, TeamCity/Jenkins/...), который автоматически запускает rake spec для каждой регистрации. Вы не хотите создавать отдельные конвейеры сборки для каждой ветки, только ради использования отдельного rvm use... для каждой ветки. Вы просто хотите, чтобы версия Ruby выбиралась автоматически в зависимости от ветки

• У вас жесткий контроль над окружающей средой и всеми разработчиками. Вам либо не нужно, либо диктовать, что они используют один и тот же рубин и гемсет

• Вы используете Phusion Passenger или Capistrano, которые автоматически читают файлы .rvmrc и выбирают правильный рубин для развертывания/хостинга

Также обратитесь к рекомендациям RVM Best Practices

ПРОТИВ:

• Вы можете скомпилировать свой собственный Ruby в RVM с некоторыми экспериментальными патчами и присвоить ему собственное имя.

  например, rvm install 1.9.3 --patch railsexpress,falcon --name ruby-1.9.3-perf

  В приведенном выше примере я установил Ruby 1.9.3 с небольшими скоростными исправлениями (кстати, они потрясающие), но вместо того, чтобы называть его 1.9.3, я называю это своим именем. Я бы сказал, что rvm use ruby-1.9.3-perf когда мне это нужно. В этом случае, если проект имеет свою собственную .ruby-version, тогда это испортит мою среду. В моем проекте эти исправления являются стандартными, и мы активно рекомендуем их. Но как разработчики называют результирующий скомпилированный Ruby до них

• Точно так же люди используют разные гемзеты. Некоторые не используют gemset вообще. Некоторые используют один и тот же набор gemset с разными (но похожими) рубиновыми проектами. Учитывая это, опять же один .ruby-gemset также не работает для всех

• У вашего проекта есть неясная рубиновая версия, которая просто говорит 1.9.3. Сначала разработчики установили последнюю версию Ruby 1.9.3-p329. Но позже они просто обновляют RVM/Rbenv (поскольку они работают над другими проектами). Их .rvmrc или .ruby-version просто ломается, так как последняя версия Ruby, зарегистрированная в RVM/Rbenv, только что изменилась с ruby-1.9.3-p329 на .ruby-1.9.3-p362, и она скажет ruby-1.9.3-p362 не установлен. Этот сценарий часто случается.

Если вы укажете правильное полное имя для своей версии Ruby (включая уровень патча), вы должны быть в порядке. Скажем, ваш проект .ruby-version говорит ruby-1.9.3-p329. Легко скомпилировать ваш собственный Ruby со всеми этими патчами и по-прежнему просто настраивать имя ruby-1.9.3-329 чтобы файлы конфигурации ruby-1.9.3-329 этот рубин вместо стандартного рубина.

Ответ 3

Я бы включил .ruby-version - вы и кто-либо другой, работающий над проектом вместе с вашими серверами, должны использовать ту же версию Ruby.

.ruby-gemset.... до вас, я думаю.