3

私のアプリケーションはMochiwebを使用しています。私が理解しているように、rebar実行時にGithubから最新バージョンをフェッチします。これは、次makeの行があるためですrebar.config。

{deps, [
  {mochiweb, ".*",
   {git, "git://github.com/mochi/mochiweb.git", "master"}}

私のアプリケーションにはVCSがあり、それはgitです。したがって、基本的に私は別の内部に1つのgitリポジトリを持っています：

myapp
 .git
 deps
  mochiweb
   .git
 src
 etc

別のリポジトリ内にgitリポジトリを追加するのは良い考えではないことを私は知っています（git add .）。代わりに、Gitサブモジュール機能を使用する必要があります。

そこで、deps/mochiwebメインのgitリポジトリにサブモジュールとしてディレクトリを追加しました。

問題は、別の開発者がメインリポジトリを複製するときに、取得するために最初にサブモジュールinitとサブモジュールを複製する必要があることです（そうでない場合は空になります）。updatedeps/mochiweb

開発者がmakeメインリポジトリのクローンを作成した直後に実行する場合、Makefileは次のように言います。

ERROR: Dependency dir deps/mochiweb failed application validation with reason:

{missing_app_file,"deps/mochiweb"}

make: *** [all] Error 1

私の質問は次のとおりです。Gitサブモジュールを使用せずに他の開発者が簡単に更新できるように、Erlangアプリのdepsに別のアプリを追加する適切な方法は何ですか？

4

3 に答える 3

5

Erlangアプリのdepsに別のアプリを追加して、gitサブモジュールを使用せずに他の開発者が簡単に更新できるようにする適切な方法は何ですか？

アプリをrebar.configに追加し、以下を使用します。

./rebar update-deps

更新用。初めて使用する必要があります：

./rebar get-deps

参照：https ：//github.com/basho/rebar/wiki/Rebar-commands

ここで、エラーに戻ります。

私の感じでは、おそらくGitサブモジュールで遊んだ結果として、あなたのdepsにはmochiwebの（ほぼ）空のディレクトリがあります。コマンドを実行するとget-deps、ディレクトリがすでに存在するため、rebarはmochiwebをサイレントに破棄します。ただし、OTPアプリケーションを想定しておりmochiweb.app、そこにないファイルを探します（ディレクトリは空です）。したがって、エラー。私の解釈が正しければ、次のようにすることができます。

rm -rf deps/mochiweb
./rebar get-deps

ただし、rebar.configを確認すると役立ちます。

于 2012-05-17T07:31:28.597 に答える
4

内部のErlangプロジェクトでは、依存関係を参照するためにGitサブツリーマージアプローチを使用しています。私の見解でrebar get-depsは、ホストされたプロジェクトの依存関係を取得するための手軽な方法ですgithubが、企業環境ではそれほど良くありません。

  1. githubすべてのビルドマシンからアクセスできる必要があります（依存関係のソースはハードコードされていますrebar.config）
  2. あなたはそれほど正確ではない依存プロジェクトのビジョンに依存しています（特定のコミットを指すことができますか？）。過去のプロジェクトの状態（その時点でのすべての依存関係を含む）を再現できないだけでなく、さらに悪いことに、依存関係が更新されるとgithub（バージョンを更新せずに）プロジェクトが簡単に壊れてしまう可能性があります。
  3. 依存プロジェクトをカスタマイズしたい場合はどうなりますか？依存プロジェクトの「rebar.config」ファイルの小さな変更のように？

したがって、依存するプロジェクトごとget-depsに個別のブランチ（+特定のプロジェクトを指すリモート）を使用する代わりに、gitサブツリーがプロジェクトブランチの「dep」ディレクトリにマージします。github事実上、すべての依存関係をメインブランチに保存しますが、そうすることで上記のすべての問題を解決できます。

  1. 内部のgitリポジトリからプロジェクトのメインブランチ（またはdevなど）をプルすることで、コードベース全体を取得できます。すぐに構築できます。
  2. すべての依存関係の正確なバージョンはメインブランチにサブツリーマージされ、必要な場合にのみ新しいバージョンの依存関係に更新されます。依存関係ブランチに切り替えるだけで、git pullサブツリーは依存関係の特定のバージョンをメインにマージします。ブランチ。プロジェクト全体の過去のバージョンはいつでも入手できます。
  3. 依存関係を更新するときは、依存関係を独自のブランチ（または別のカスタマイズされたブランチ）でカスタマイズできgit mergeます。変更を加えた最新のコードを使用する必要がありますが、通常は問題ありません。リモコンを自分のリポジトリ（フォークオンgithubまたは内部）にポイントすることもできます。

もちろん、プロジェクトをこの形式（すべての依存関係を含む）で「github」に公開することはありませんが、別のブランチですべての依存関係を（「dep」フォルダーを削除することで）削除して結果を公開できます。このアプローチの欠点は、依存関係の更新に少し手間がかかることです。更新するすべての依存関係に対して+rebar get-depsを実行する必要はありませんが、これは厳密な依存関係管理とビルドの容易さの結果です。git pushgit merge -s subtree

于 2012-05-18T05:00:23.677 に答える
1

鉄筋のget-depsコマンドを探していると思います。良い例として、Riakが使用するMakefileとrebar.configを見てください。

于 2012-05-16T20:42:19.837 に答える