1

インデントにタブを使用するコードベースのほとんど (95% 以上) を歴史的に持っている、かなり大規模な古めかしい Python プロジェクトがあります。Mercurial は VCS として使用されます。

タブの使用にはいくつかの不都合があります。Python コミュニティ内では 4 つのスペースが一般的なインデント方法になったようで、ほとんどのコード分析/フォーマット ソフトウェアは何らかの方法でタブを台無しにします。また、プロジェクトに取り組んでいるチーム メンバーのほとんど (実際にはほとんどすべて) は、タブよりもスペースを好むため、切り替えたいと考えています。

したがって、特定のコード行の最新の修飾子が誰であったかを追跡する機能を失うというこの恐れがあります...すべてのコード行が、タブベースのインデントからスペースベースのインデントを使用するように変換された場合、変更は Mercurial リポジトリにコミットされます。まさにそれが起こります。そして、この機能 (hg annotate) は、それを犠牲にする可能性を考えるにはあまりにも便利です。

Mercurial hg annotate 機能を失うことなく、プロジェクト全体でインデント方法を切り替える方法はありますか? あるとすれば、最も痛みのない方法は何ですか?

4

2 に答える 2

3

各タブを 4 つのスペースに置き換えたとしてもannotate、空白の変更を無視するスイッチを使用するだけで、からかなり正しい結果を得ることができます。

hg annotate -b text.txt

-w比較ですべての空白を無視するために使用することもできますが-b、最も一致するように見えました: 一部の空白が別の空白に変更された場合は無視されます。

ただし、これは、空白のみが変更されたすべての行を無視し、インデントの変更を無視し、行の以前の変更に起因するもののままにします。

詳細については、 hg help annotateを参照してください。

于 2013-08-09T15:50:37.653 に答える
1

新しいリポジトリを作成し、適切なスクリプトを使用して、以前の履歴の各コミットを入力することができますが、実際にコミットされたものから自動的に変更されたファイルと、タブが置き換えられた同じものを使用できます。基本的に、スクリプトは初期ファイル セットをチェックアウトし、コミットの詳細を取得してファイル セット内のタブを置き換え、元のコミットの詳細で新しいリポジトリにコミットする必要があります。次に、次の変更セットに移動し、パッチを生成して適用し、タブを再度フィルタリングしてコミットします。同様のことについてのブログがここにあります。

これはオフラインで自動的に行うことができ、合意された日にサーバー上のリポジトリを変更したリポジトリに置き換えます (もちろんコピーを保持します)。次の作業を行う前にプルする必要があることをチームに伝えることを忘れないでください。日。

pre-commit hookを実装することを強くお勧めします。これにより、誰かが古い形式のファイルをチェックインしようとしても汚染されないようにすることができます。プロセスを開始する前に、それらを新しいリポジトリに配置する価値があるでしょう。

アップデート

上記を書いた後、私は最終的に正しい検索用語を思いつき、最初のコメントを引用するために、必要なことを正確に行う必要があるhg_cloneを見つけました。

# Usage: hg-clone.rb SOURCE-DIR DEST-DIR --target TARGET-REVISION --cutoff CUTOFF-REVISION --filter FILTER

#
# This program clones a mercurial repository to a new directory, changeset by changeset
# with the option of running a filter before each commit. The filter can be used for
# example to strip out secret data (such as code for unused platforms) from the code.
#
# --target TARGET-REVISION
#    The revision that the DEST-DIR should be updated to. This revision, and all its parent revisions
#    will be copied over to the dest dir. If no TARGET-REVISION is specified, the latest revision in
#    the repositiory will be used.
#
# --cutoff CUTOFF-REVISION
#    If specified, this should be a short revision number that acts as a cutoff for synching. If you
#    specify 100 for instance, no revisions before 100 will be brought over to DEST-DIR. Revisions
#    that have parents earlier than revision 100 will be reparented to have 100 as their revision.
#
# --filter FILTER
#    Specifies a program that should be run in the DEST-DIR before committing each revision.
于 2013-08-09T18:02:22.887 に答える