1

Make は純粋にタイムスタンプ指向です。ソースがターゲットよりも古い場合、ターゲットは再構築されます。これにより、メジャー バージョン管理の迂回を行うと、大きなアプリケーションで長い再コンパイルが発生する可能性があります。

例を挙げましょう。まだマージされていない古い機能ブランチがあり、それがどのように機能しているかを確認したいとします。したがって、マスターから始めて、そのブランチをチェックアウトし、マスターをそれにマージしてからコンパイルします。すべて非常に問題なく、機能が小さければ、マスターとの違いも小さくなるはずです。ただし、フィーチャー ブランチが非常に古い場合は、ファイル システムの多くの変更を取り消してからやり直しました。

2 番目の例として、コードの再コンパイルを必要としない git つるはしを超えた複雑な条件を探しながら、コードの大部分を 2 分割することを想像するかもしれません。探していたものが見つかったら、マスター ブランチに戻る必要があります。しかし、二分ウィンドウが十分に大きければ、その間に多くのファイルが変更された可能性があります。

だから私が知りたいのはこれです:前もって変更時間のスナップショットを取り、これらの操作によってコンテンツが復元されたファイルのmtimesを復元できるツールはありますか? もちろん、完了したら明示的に伝える必要があります。これの要点は、その間にファイルが変更される可能性があるということです。

汎用ツールの場合、大きなソース ツリーのスナップショットを作成するのにもかなりの時間がかかるため、git と統合するツールを探していると思います。そのため、変更されたファイルを追跡できるものでなければなりません。 、例えば、いくつかのフックを使用します。一方、git statusすべてのファイルの内容もチェックする必要がある場合は、汎用ツールのコストはそれほど高くないかもしれません。

そのようなツールはありますか、それとも自分で作成する必要がありますか?

元の作成/変更されたタイムスタンプを使用して古いファイルをチェックアウトすることは、私が望むものとはまったく異なり、いずれにしても時間がかかりすぎることに注意してください。

4

2 に答える 2

1

適切なツールが見つからなかったため、独自のツールを作成することになりました。思ったよりも簡単でした。これは主に、これらすべてのファイルのコンテンツをハッシュするのに、思ったよりもコストがかからなかったためです。少なくとも、ホットなファイル システム キャッシュの場合はそうです。

于 2014-04-25T16:16:45.417 に答える
0

派生バージョンの作成にコストがかかりすぎる場合、およびこの種のブランチの切り替えと古いベースラインへの回帰が頻繁に行われる場合 (なぜですか?)、これらの派生バージョンを入力と一緒にチェックインすることを検討する必要があります。それらにラベルを付けます。

于 2014-04-24T14:24:52.147 に答える