2010-12-14 4 views
7

Mercurialで追跡したソースファイルにカスタムメタデータを添付する必要があります。 svn propertiesコマンドはまさに私が必要とするものです。svn propsetのようなMercurial拡張機能はありますか?

propset,propget,propdelなどのようなコマンドを提供する水銀拡張がありますか?

拡張子がない場合、どうしてですか?
Mercurialを使用しているときにカスタムメタデータの代わりとなる/より良いアプローチがありますか?
カスタムメタデータは他の誰にも有用ではありませんか?
拡張機能は本当に必要ですがまだ書かれていませんか?

追加情報:役立つ場合は。私が追跡しているメタデータは、各ファイルがcodereviewed、unittested、qa'dなどであるかどうかです。このデータはトレーサブルである必要があり、ブランチ/クローン間のマージは十分に細かいものではありません。

+1

水銀メールリストを試しましたか?そこにもいくつかの回答があるかもしれません。 (いくつかのMercurial開発者だけがSOにあり、悲しいことにすべてではありません)。 – Macke

答えて

4

Mercurialの考え方は、ファイルとファイルのみを追跡することです。 Mercurialはフォルダを知らないので、空のフォルダにチェックインすることさえできません!

だから、ここの回答は以下のとおりです。

  • 私は何をしたいん任意の拡張子を見つけることができません。

  • データをフラットファイルに保存し、それを処理するためにいくつかのスクリプトを使用するという、Mercurialのやり方は必要なことです。 :(

私はそれについてここでは杓子定規ではありませんので、あなたの会社での場所と優れた技術的手法でかなりよく考え抜かシステムを持っているように聞こえるが、一つは、合理的な議論をすることができますあなたのメソッドは、移植性を傷つけること以外は何もしません。プロパティについては何も魔法はありません。svn proplist -v .をツリー上で実行し、それを隠しファイルにダンプします-.trackingのようなものを明示的に通常のファイルとマージします。とにかくプロパティをマージする必要があるので、実際に仕事を追加してください。

私はあなたのために働くことを望みます!

4

Mercurialの規約では、ファイル名.hg*をリポジトリのルートに配置し、ファイル名をプロパティ値にマップするための辞書(ある種の)として使用します。たとえば、svn:eol-styleの代わりに、hgeol拡張子は.hgeolファイルを使用します。

コードレビューの場合は、このメタデータを操作できる別の拡張機能を作成し、その拡張機能をマージフレンドリな形式で保存することをおすすめします。

0

私はこの質問に本当に遅れた疑似回答を追加するつもりです。なぜなら、私を含めて多くの、多くの人々がMercurialを使っている人が、私たちが持っていたいと思っているものと期待しているもの、 svnプロパティのようなツール。

私が知る限り、Mercurialの拡張はありません。まだ。

はい、Mercurialの方法はファイルとファイルのみを追跡するようです。そのような拡張を行うには、repo/.hg *ファイルに必要なメタデータを置くことが正しいかもしれません。

OK。私はそのことに取り組んできました。ツールを書く前に手作業でやっています。

バージョン管理された.hgファイルアプローチの弱点は、非先端バージョンをチェックアウトすると、 "hg update -r OLD-VERSION"を実行すると、旧バージョンのメタデータが取得されます。

私は重要なことは、メタデータを... repo/.hg *ファイルに入れることです。

ほとんどの操作は、このようなファイルの最新バージョンで実行する必要があります。私。私はそのようなメタデータファイルはバージョンを超越している、つまりバージョン管理されたいと思っていますが、理想的な状況では、古いバージョンのファイルをチェックアウトしている可能性がある通常のバージョンファイルに重ねて表示されます。

さらに、多くの場合、そのようなメタデータファイルの分岐を別々に処理する必要があります。例えば。すべてのブランチの説明を一緒に書き込もうとしているファイルを想像してください。おそらく、 "branch1.1はbranch1のより新しいバージョンです"のように、ブランチを比較します。その説明がどちらのブランチにも存在することは望ましくありません。むしろ、両方のブランチに同時に、同時に、両方のブランチに変更が反映されるようにする必要があります。

このような推定拡張子は、 "hg cat -r tip ... repo/.hg-my-new-metadata"のいずれかで動作します。あるいは、バージョン管理されたファイルを通常のバージョンの超過メタデータファイルでオーバーレイすることになります。

私はsubreposでこれを行うにいくつかの進歩を遂げている。

superrepo 
    files // normally-versioned-files <-- a subrepo 
    metadata // version transcending metadata <-- a subrepo 

これは私がチェックアウトするので、それはかなりありませんファイル

の古いバージョンと一緒に最新のメタデータをチェックアウトすることができます特定のバージョンのスーパーレポが古いバージョンのメタデータ・サブペーポを取得する可能性があります。しかし、少なくとも新しいバージョンはサブバージョンにあります。

私はまた、あなたが隣のsubrepoにメタデータを置くかどうか、ということに注意してください、または同じレポでそれを維持する(ただし、先端に動作)してみましょう、あなたは

hg clone -r OLD-REVISION repo newrepo 

を行うことができます問題がありますこれにより、OLD-REVISIONより後でメタデータが取り除かれます。 「OLD-REVISIONはすべてのテストに合格しました」というメタデータを含めます。つまり、OLD-REVISIONに適用される可能性のある最新のリビジョンのメタデータを取り除きます。

同じ問題がhgタグで発生します。

「よく、決してそれをしない」と言う人もいます。残念なことに、これはしばしばリポジトリを「整理」する方法として推奨されます。

Mercurialでこれを避けるのは難しいようです。

関連する問題