6

$Log$キーワードの使用について、毎年のように議論されているようです。私の見解は次のとおりです。

$Log$白熱の死です。

それが行うのは、関連性の低いスパムをソース ファイルに詰め込むことだけです。$Log$ から取得できる可能性があると誰もが考える情報は、バージョン管理システムから容易に入手できます (また、より正確である可能性が高くなります)。

では、ここで質問です。「昔ながらの」コーダー ($Log$ がソース コードの変更を管理する方法だと考えている人) に、現在はより優れたツールがあることをどのように説明しますか?

$Log$ に関する CVSNT の発言は良い出発点ですが、十分に指摘されていません。これまでのところ、私がなんとか思いついたワンライナーに最も近いものは「$Log$願い事です。ファイルにスパムされたものが、これに実際に起こったことと何らかの関係があることを望んでいます。ファイル。"

明確にするための追伸: 私が「オールドスクール」と言うとき、私は態度が古いことを意味します。私の最初のプログラミングの給料 (そしてそれも非常に控えめなもの) は 1986 年のいつかのことで、$Log$ が良い考えだとは思いもしませんでした。

4

4 に答える 4

8

Subversion FAQにも良い説明があると思います。

ブランチ間で変更をマージし始めた瞬間、$Log$ は恐ろしいものです。このキーワードの性質上、自動的に解決することはできません。

于 2009-04-08T20:09:04.497 に答える
4

他の人が言ったことに加えて、コミット メッセージにコメント (/* ... */) を入れてみてください :->。

于 2009-04-08T20:12:26.140 に答える
2

ソース ファイル内の有用なビットの量は、その $Log$ ステートメントで変更が加えられるにつれて徐々に減少します。CVS から取得したいくつかのファイルにそれがあり、$Log$ ステートメントの行数は、ファイル内の実行可能コードの実際の 10 倍のオーダーでした。また、いくつかのブランチからの不適切なマージが原因で、いくつかのグループの重複が発生しました。

于 2009-04-08T20:17:32.603 に答える
1

不変のメタデータをファイルに埋め込むことを検討してください ( mayを強調)。 (私と「年長の学生」の間の議論を参照してください:埋め込みバージョン番号 - 善か悪か? )。

私は常にその慣行を悪 (メタデータ情報をデータに混合すること) と考えてきましたが、「マージ地獄」を導入すると、適切なマージ マネージャーを使用して、固定形式の不変メタデータに対して機能する可能性があると主張することができます。お気に入り：

  • $Revision$ $Revision: 9.13 $
  • $Date$ $Date: 2009/03/06 06:52:26 $
  • $RCSfile$ $RCSfile: stderr.c,v $

しかし、ログのような変更可能なメタデータは? 形式や内容が不明ですか？それは必ず失敗します。

于 2009-04-08T20:18:50.493 に答える