3

これが状況です。私は大規模な Rails 3.2.13 アプリ (Ruby 1.9.3、Bundler 1.3.5) に取り組んでいます。最近、一部のコンポーネントを gem/engine に分割することで、このアプリのモノリシックを緩和するプロセスを開始しました。ただし、ソース コードは同じ git リポジトリに保持しています。したがって、次のようなファイル構造があります。

APPNAME
|-app
|-gems
|---engine1
|---engine2
|-lib

等

次に、Gemfile は次のようになります。

gem 'engine1', :path => File.expand_path('../gems/engine1', __FILE__)
gem 'engine2', :path => File.expand_path('../gems/engine1', __FILE__)

ここまでは順調ですね。私の問題は、Gemfile.lock開発者間で一貫性がなくなったことです。ソース管理から変更を取得して実行するたびにrspec、差分が次のように変更されますrails server。Gemfile.lock

 PATH
-  remote: /Users/OTHER_DEVELOPER/PATH_TO_APP_SOURCE/gems/engine1
+  remote: /Users/ME/APPNAME/gems/engine1

私たちは常に、Gemfile.lockソース管理にチェックインするためのベスト プラクティスと考えられる方法に従ってきましたが、今ではそれが git の頭痛の種になっています。以前にこの問題に対処した人はいますか? 解決策のアイデアはありますか？

4

1 に答える 1

1

ここでの問題は、gem を意図しない方法で使用していることです。これらは宝石であり、DLL ではありません。

gem のアプローチが必要な場合は、それらをプライベート サーバーでホストし、GEMFILE でそのサーバーを参照します。

Ruby で DLL のようなアプローチが必要な場合は、ライブラリごとにフォルダーを使用するだけです。

于 2013-05-30T14:09:33.703 に答える