1

システム内の一部のソース ファイルで、ソース管理チェックイン コメントが含まれているものと含まれていないものがあるという不一致に気付きました。これらのコメントは、チェックイン時にファイルの先頭に自動的に追加されます。

    * $Log:   //vm1/Projects/Morpheus/Sleep.bdy-arc  $
--
--   Rev 1.14   Apr 14 2009 15:32:52   John Smith
--Fixed bugs 2292 and 2230.

これは、私が一緒に仕事をしたすべての会社でかなり蔓延しているようですが、要点を理解するのに苦労していることを告白しなければなりません. 一般的に、コメントはあまり良くなく、多くの場合、離れて久しい人々によって残されます。たとえコメントが高水準であっても、それらを物理的なコードの変更に結び付けるのは困難です。

また、チェックインしているファイルを物理的に変更していることも気になります。これは、コンパイルされるファイルではそれほど問題にならないかもしれませんが、JavaScript ファイルなどの他のファイルでは問題になる可能性があります。

本当に、私の質問は、最初のインスタンスでこの機能を提供する背後にあるコンセプトの動機は何でしたか? これらのコメントが実際に役立つと思う人はいますか?

また、これがソース管理システム内で一般的にサポートされている機能であるかどうかも知りたいです。PVCS、VSS、および Subversion ( Subversion Keyword Substitution ) でそれを認識していますが、より一般的な DVCS のいくつかでも利用できるのではないかと思います。

いつもお世話になっております。

4

3 に答える 3

5

おっしゃる通りです - これは結局、リビジョン管理システムの非常に便利な機能ではありません! はい、企業は監査証跡を好みますが、これはリビジョン管理システムの log コマンドによって提供されます。はい、それはリビジョン管理システムが利用できない場合にログが利用可能であることを意味します-しかし、その場合、Fixed bug 1234おそらくあまり意味がありません:-)そして、あなたがほのめかしたように、変更を特定の行に結び付けるために、リビジョン管理システムの助けが必要です。

ファイルがコミットされているときにファイルを変更すると問題が発生する可能性があることも正しいです。同僚が自分のコードをコンパイルしてからコミットしたことを注意深く確認した後、コミットしたファイルが失敗したために炎上するだけの問題を見たことがあります。コンパイルしないでください。コメントは のようなものであることが判明しClean up /tmp/*.txt、C コンパイラは をコメント開始文字として扱って/*いました (そして、既にコメント内にあったため、不平を言いました)。

ファイル内のログに関するもう 1 つの問題は、線形の作業にのみ意味があることです。複数のブランチを使用して開発している場合 (git/mercurial/bazaar などの分散ソース ツールが推奨する方法で)、ソース ファイル自体にログを保持するだけでは機能しません。ほとんどの場合、マージの競合が発生します。

このため、最新のツールはこの機能を実装しない傾向があります。実際、 subversion はそうではありません。そのキーワード置換は、意図的にログ履歴を含めることを許可していません。

于 2010-05-17T14:37:59.070 に答える
1

So really, my query is what was the motivation in concept behind providing this functionality in the first instance? Does anyone actually find these comments useful?

When the sources are mirrored to an external location (source packages, source code index etc) then the version control information might not be available. For such cases this information might be useful.

于 2010-05-17T13:59:06.307 に答える
1

本当に、私の質問は、最初のインスタンスでこの機能を提供する背後にあるコンセプトの動機は何でしたか? これらのコメントが実際に役立つと思う人はいますか?

一部の企業では、監査管理が大きな懸念事項となっています。監査者は、インシデント システムから実際のコード変更まで追跡できることを望んでいます。 Fixed bugs 2292 and 2230.コードからインシデント システムまでのトレース バックを提供します。

一部の企業では、同じ理由で、ソース管理変更ログのコメントの一部としてインシデント番号が必要です。

于 2010-05-17T14:16:33.000 に答える