12

pre-commit スクリプト内で、? に起因するコミットを特定することは可能svn mergeですか?

svnlook changed ...変更されたファイルを表示しますが、マージと手動編集を区別しません。

merge理想的には、標準とを区別したいと思いmerge --reintegrateます。

バックグラウンド：

プロジェクトに SVN の使用ポリシーを適用するために pre-commit フックを使用する可能性を探っています。

ポリシーの 1 つは、一部のディレクトリ ( など/trunk) を直接変更してはならず、機能ブランチの再統合によってのみ変更する必要があると述べています。したがって、pre-commit スクリプトは、ブランチの再統合を除いて、これらのディレクトリに加えられたすべての変更を拒否します。

何か案は？

アップデート：

コマンドを調査しましたが、最も近いのは、ディレクトリsvnlookのプロパティへの変更を検出して解析することです。svn:mergeinfoこのアプローチにはいくつかの欠点があります。

  1. svnlookプロパティの変更にフラグを立てることはできますが、どのプロパティが変更されたかはわかりません。proplist(前のリビジョンとの差分が必要です)
  2. の変更を調べることでsvn:mergeinfo、実行されたことを検出できsvn mergeます。ただし、コミットが純粋にマージの結果であるかどうかを判断する方法はありません。マージ後に手動で行った変更は検出されません。(関連記事:別のパス/リビジョンに対するトランザクション ツリーの差分)
4

2 に答える 2

2

私は結局、理想的ではない解決策に頼ることになりました。つまりsvn:mergeinfo、変更ツリーの最上位ディレクトリにあるプロパティの変更を検出することです ( で実装されていますSVNTransaction.is_merge_operation())。

マージのみのコミットと、追加の変更も含むコミットを区別することはできません。これは、マージと共にコミットされた場合、そのツリーの下で発生するすべての変更が検出されないことを意味します。考えられる解決策は、トランザクション ツリーをマージ ソースと比較することかもしれませんが、それを実現する方法はまだわかりません(これには、競合解決の結果としての変更も考慮する必要があります)。

mergeまた、 aと a を区別することもできませんmerge --reintegrate。

svn:mergeinfoその他の制限には、ユーザーが変更可能で、古いバージョンの subversion では使用されないへ​​の依存が含まれます。

問題のコミット スクリプトは、アクセス制御メカニズムではなく、プロジェクトのガイドラインに違反するコミットにフラグを立てるための穏やかなリマインダーとして意図されているため、上記の制限はショーストッパーではありません。しかし、私はまだ改善を求めています。コメントとさらなる提案を歓迎します。

于 2012-12-14T17:04:45.857 に答える
2

残念ながら、Subversion はマージのみのコミットを強制しません。

ブランチへのアクセス権があれば、マージ後、コミット前に何でもできます

また、サブバージョンのマージはクライアント側で発生します

多くのコード リポジトリ ツールがサーバー上でマージされます。つまり、あるストリームから別のストリームにのみパッチを移動するように強制します。

于 2012-05-04T16:29:52.377 に答える