El verdadero problema ocurre cuando se está trabajando en una aplicación de código abierto Rails que tiene que tener un adaptador de base de datos configurable. Estoy desarrollando la rama Rails 3 de Fat Free CRM. Mi preferencia es postgres, pero queremos que la base de datos predeterminada sea mysql2.
En este caso, Gemfile.lock aún necesita ser registrado con el conjunto predeterminado de gemas, pero tengo que ignorar los cambios que le he hecho en mi máquina. Para lograr esto, corro:
git update-index --assume-unchanged Gemfile.lock
y al revés:
git update-index --no-assume-unchanged Gemfile.lock
También es útil incluir algo así como el siguiente código en su Gemfile. Esto carga la joya del adaptador de base de datos apropiado, en función de su database.yml.
# Loads the database adapter gem based on config/database.yml (Default: mysql2)
# -----------------------------------------------------------------------------
db_gems = {"mysql2" => ["mysql2", ">= 0.2.6"],
"postgresql" => ["pg", ">= 0.9.0"],
"sqlite3" => ["sqlite3"]}
adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))
db = YAML.load_file(db_config)
# Fetch the first configured adapter from config/database.yml
(db["production"] || db["development"] || db["test"])["adapter"]
else
"mysql2"
end
gem *db_gems[adapter]
# -----------------------------------------------------------------------------
No puedo decir si esto es una buena práctica establecida o no, pero me funciona bien.
Relacionado: http://stackoverflow.com/questions/14034561/should-gem-file-lock-be-committed-to-source-control-on- windows – ripper234
Si encontraste tu aquí porque tiene cajas de Linux y Windows que comparten el mismo repositorio, vea la respuesta de Joe Yang. En el momento de escribir esto, ocupa el tercer puesto. También vea http://stackoverflow.com/questions/14034561/should-gem-file-lock-be-committed-to-source-control-on- windows –