Gibt es eine Mercurial Erweiterung wie svn propset?

Question

Ich brauche benutzerdefinierte Metadaten meiner Quelldateien zu befestigen, dass bei über Mercurial verfolgt. Die svn Eigenschaften Befehle sind genau das, was ich brauche.

Gibt es eine Quecksilber-Erweiterung, die Befehle ähnlich wie propset bietet, propget, propdel, etc?

Wenn es keine Erweiterung ist, warum nicht?
Gibt es eine Alternative / besserer Ansatz für benutzerdefinierte Metadaten bei der Verwendung von Mercurial?
Ist benutzerdefinierte Metadaten nicht sinnvoll, alle anderen?
Ist die Erweiterung teuer erwünscht, aber nur noch nicht geschrieben?

zusätzliche Informationen : Wenn es hilft. Die Metadaten I Tracking bin, ob jede Datei Diese Daten müssen codereviewed, unittested, qa'd wurde, usw. zwischen den Zweigen / Klone werden nicht feinkörnig genug nachvollziehbar und verschmilzt sein.

Answer 1

Mercurial Philosophie ist, dass Sie Dateien und nur Dateien zu verfolgen. Sie können nicht einmal in einem leeren Ordner überprüfen, weil Mercurial nicht über Ordner nicht kennt!

So, hier sind die Antworten:

• Ich kann keine Erweiterung finden, das tut, was Sie wollen. (Sie können Ihre eigenen natürlich schreiben.)

• Die Mercurialful Art und Weise zu tun, was Sie wollen, ist, die Daten in einer flachen Datei zu speichern und einige Skripte zu verwenden, sie zu verarbeiten. : (

Es klingt wie Sie eine ziemlich gut durchdachtes System an Ort und Stelle und der guten Ingenieurpraxis in Ihrem Unternehmen haben, damit ich nicht hier darüber pedantisch sein, aber man kann ein vernünftiges Argument, dass Ihre Methode tut nichts außer Schmerz Portabilität. Es über Eigenschaften nichts Magisches ist, würde ich gerade einen svn proplist -v . auf Ihrem Baum, dump ausführen, um versteckte Dateien - so etwas wie .tracking - nur explizit zusammen mit Ihrer normalen Datei zusammenführen. Dies fügt eigentlich keine Arbeit, da Sie merge Eigenschaften haben trotzdem.

Ich hoffe, das funktioniert für Sie!

Answer 2

Die Mercurial Konvention Dateien Namen .hg* in die Wurzel des Repository zu setzen, und sie als Wörterbücher (irgendeiner Art) Dateinamen Eigenschaftswerte zuordnen. statt svn:eol-style Zum Beispiel verwendet die hgeol Erweiterung ein .hgeol Datei.

Bei Code-Review-Tracking, würde ich empfehlen, eine weitere Erweiterung zu schreiben, die Manipulation dieser Metadaten ermöglicht, und haben diese Erweiterung Speicher seinen Zustand in einem Merge freundlichen Format.

Answer 3

Ich werde eine wirklich spät quasi-Antwort auf diese Frage hinzuzufügen, da es sich um eine, die viele, viele Menschen mit Mercurial, mich eingeschlossen, fragt - etwas, das wir haben wollen, und zu erwarten zu haben, nach der Verwendung von andere Tools wie sVN-Eigenschaften.

Soweit ich das beurteilen kann, gibt es keine solche Erweiterung für Mercurial. noch.

Ja, scheint der Mercurial Weg, um Dateien zu verfolgen und nur Dateien. Und es könnte sein, dass sie Weg nach rechts eine solche Erweiterung ist es, die notwendigen Metadaten in ... Repo- / .hg * Dateien abgelegt werden.

OK. Ich habe mit dem Herumspielen. Dinge tun, von Hand, bevor Schreib Tools versuchen.

Der Schlüssel Schwäche des versioniert .hg Dateien Ansatzes ist, dass, wenn Sie eine nicht-Spitze-Version überprüfen, z.B. "Hg update -r OLD-VERSION", Sie eine alte Version der Metadaten erhalten.

ich glaube, das Wichtigste, kann daher sein, die setzen Metadaten in ... Repo- / .hg * Dateien.

Aber ... die meisten Operationen sollten mit oder auf die neueste Version dieser Dateien durchgeführt werden. D. h Ich denke, solche Metadaten-Dateien „transzendieren“ Versionen - das heißt, sie werden versioniert wollen, aber in einer idealen Situation, die Sie könnten sie als überlagerte sich vorstellen, auf die normalerweise versioniert Dateien, dass Sie eine ältere Version von ausgecheckt haben

.

Darüber hinaus ist in vielen Fällen Sie wollen, dass die Verzweigung solcher Metadatendateien separat behandelt werden. Z.B. stellen Sie sich eine Datei, in der Sie versuchen, eine Beschreibung aller Zweige zu schreiben, zusammen. Vielleicht Zweige zu vergleichen, wie „branch1.1 eine neuere Version von branch1 ist“. Sie wollen nicht, dass die Beschreibung auf beiden Zweige zu sein; oder, besser gesagt, wollen Sie es auf beiden brancges sein, zur gleichen Zeit, und Sie Änderungen an beiden Zweigen reflektiert werden.

Eine solche vermeintliche Erweiterung würde entweder arbeiten auf "hg cat -r Spitze ... Repo- / .hg-my-new-Metadaten". Oder es wäre irgendwie überlagern die versioniert der Dateien mit den normalerweise Version transzendierenden Metadatendateien.

Ich habe einige Fortschritte gemacht dies mit subrepos auf tun:

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

Dies ermöglicht es mir, die neuesten Metadaten neben einer älteren Version der Dateien zu überprüfen,

Es ist noch nicht ganz da, weil eine bestimmte Version des superrepo Check-out können alte Versionen der Metadaten subrepo erhalten. Aber zumindest sind die neueren Versionen in der subrepo.

Lassen Sie mich auch zur Kenntnis, dass, ob Sie die Metadaten in einem benachbarten subrepo setzen, oder es in der gleichen Repo halten (aber arbeiten an der Spitze), gibt es ein Problem, dass Sie tun können,

hg clone -r OLD-REVISION repo newrepo

Dies wird Metadaten Streifen aus später als OLD-REVISION. Einschließlich der Metadaten, die besagt, dass „OLD-REVISION alle Tests bestanden“, das heißt es wird Streifen aus Metadaten aus einer späteren Revision, die OLD-REVISION gelten könnten.

Das gleiche Problem tritt mit hg-Tags.

Man könnte sagen: „Nun, das nie tun“ - nie Geschichte Streifen aus. Leider, die oft als eine Art von „aufzuräumen“ das Repository empfohlen wird.

Es scheint schwer, dies mit Mercurial zu vermeiden.