正しくフォーマットされていないPerlコードを含む既存のSubversionリポジトリをクリーンアップしたいと思います。かなり古いコードとの比較が必要かどうかわからないので、理想的にはすべてのリビジョンで同じフォーマットを使用したいと思います。
一方、すべての古いリビジョンをチェックアウトして新しいリポジトリを作成し、perltidyで再フォーマットしてチェックインすると、元のログメッセージを保持する必要があります。
それを行うためのツール/レシピはありますか?
正しくフォーマットされていないPerlコードを含む既存のSubversionリポジトリをクリーンアップしたいと思います。かなり古いコードとの比較が必要かどうかわからないので、理想的にはすべてのリビジョンで同じフォーマットを使用したいと思います。
一方、すべての古いリビジョンをチェックアウトして新しいリポジトリを作成し、perltidyで再フォーマットしてチェックインすると、元のログメッセージを保持する必要があります。
それを行うためのツール/レシピはありますか?
将来的には、Test::PerlTidyを実行しているスクリプトにsvn pre-commit フックを付けて、すべての人にコードをきちんと保つように強制することをお勧めします。
以前のすべてのコミットを変更しようとするのではなく、svn diff
古いバージョンと比較したい場合にカスタム コマンドを検討できます。何かのようなもの:
#!/bin/bash
# tidydiff.sh for tidying code before diffing
perltidy "$1" > "/tmp/$1"
perltidy "$2" > "/tmp/$2"
diff "$1" "$2"
rm "/tmp/$1" "/tmp/$2"
svn diff --diff-cmd=tidydiff.sh
古いバージョンを見たいときに使用します。
正確に何をしたいですか?すべての古いリビジョンをクリーンアップしますか?
やらないでください。履歴を破棄し、同じ Perl スクリプトを生成する必要がありますが (今は整理されています)、以前にリリースされたリビジョンを台無しにしてしまう可能性があります。その上、努力する価値はありません。
現在のリビジョンをチェックアウトし、Perl Tidy を実行してから、変更をチェックインすることをお勧めします。古いコードを変更することはありませんが、これから作業するためのクリーンなものが得られます。
もちろん、Perl コードのフォーマットが貧弱で、Perl tidy ですべてを実行したい場合は、さらに問題が発生します。誰かが再びコードを台無しにするのを防ぐものは何ですか?
また、継続的なビルド プロセスの一部としてJenkinsを検討することをお勧めします。Perl コードをコンパイルしませんが、Jenkins を使用してテストを実行し、新しい Perl スクリプトと Perl スクリプトへの変更が整理されていることを確認できます。Perl スクリプトのフォーマットが不適切な場合、ビルドに失敗し、自分自身と開発者に電子メールを送信します。
開発者は、新しい Perl コードをチェックインする前に、Perl Tidy の使用方法をすぐに習得して、ビルドに失敗したという世間の恥ずかしさに直面します。
ところで、開発チームの他のメンバーはあなたの取り組みをサポートしていますか? そうでない場合、最初にすべきことは、優れた Perl フォーマットがバグを減らすのに役立つことを彼らに納得させ、フォーマット作業を自動化するのに役立つツールを提供することです。