Was tun Sie die svn-tags-Verzeichnis für sowieso?
Ok damit wir alle wissen, die standard-SVN-set-up von
trunk\
branches\
tags\
Und ich merke, dass die Empfehlung ist, die tags haben sollten "spezielle" begeht in es. Ich habe nie wirklich verwendet die tags-Verzeichnis jedoch und ich sehe nicht ein, warum ich das jemals tun würde.
Mein Verständnis ist, dass tags\ " enthalten Dinge wie "Version1Release\, Version2Release\, ThatTimeWeUpgradedEverthing\" etc. Aber hier ist die Sache, wenn Sie gehen und eine änderung vornehmen müssen, um die Version1Release dann sollte es ein Zweig, und wenn die tags werden sollen, sich nie verändernden dann was ist der Punkt, an dem eine Kopie in der source-control überhaupt? Nur eine Anmerkung revision 712 war unsere version 1 release.
Ich denke, meine Verwirrung ist, dass es scheint, wie tags, das sind Versionen, die werden sich nie ändern sollst. Aber-source-Kontrolle ist alles über das halten eine Geschichte der wechselnden Dateien. Ich weiß, dies ist eine geringfügige organisatorische argument, aber ich bin neugierig, was die Leute denken.
- "Nur eine Anmerkung revision 712 war unsere version 1 release." Denken Sie daran, dass 69.59.196.211 ist stackoverflow.com. Nein? Warum nicht? Es ist das gleiche Konzept!
- Es ist in der Tat das gleiche Konzept. stackoverflow die IP-erinnert von der DNS-Dienst für diese Aufgabe. Es ist nicht co-opting einem anderen system in eine un-Natürliche Mode. Sie "notieren" in eine text-Datei, die Sie im source-control -, oder in Ihrem release-Dokumentation oder via zip-Datei oder 1 million andere Weise, die nicht verbunden mit einem Wandel-tracking-system zu speichern, etwas, das nie geändert werden.
- Auch, lagern Sie es nicht nehmen jeden Raum. Und Sie brauchen nicht, um den Menschen Zugang zu Ihrem Kofferraum, während immer noch das erlauben von Ihnen to download die Quelle für die release-version.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dies funktioniert gut genug für die Entwickler auf das team, vielleicht (vorausgesetzt, Sie haben ein Dokument speichern, um solche Notizen in), aber zu Fragen, wer nicht vertraut mit dem repository "nur erinnern" wird ziemlich unvernünftig ziemlich schnell.
Zum Beispiel, sagen Sie Ihr repository zur Verfügung, über die 'net. Ein Benutzer kann wählen, um check-out und erstellen Sie eine Kopie für Ihre bevorzugte, aber obskure, Aromen von *nix und wollen, schnappen Sie sich eine Version, die ist vor ein paar Versionen zurück, bevor Sie eine Funktion Hinzugefügt, die Sie nicht mögen. Tags machen diese Art der Sache einfach.
Tags eignen sich auch hervorragend als "trigger-Punkt". In meiner eigenen repositories, Begehen einen tag automatisch startet (per post-commit-hook) ein script, das erstellt, Pakete und sendet Sie an unserer web-site.
In die end-tags sind billige Kopien. Wenn Sie jemals wollen, um "Schnappschuss" - Ihre bauen in einer Weise darstellt, dass der snapshot nicht ständig ändern, markieren Sie Sie. Es ist nicht so, es kostet Sie viel. 🙂
Edit:
An die Adresse "umgesetzt als "äste" Idee — Sie sind es nicht. Wirklich. In der Tat, Subversion nicht umsetzen Verzweigung oder tagging an alle. Diese sind vollständig vom Benutzer erstellten Ideen, die beide zufällig der gleiche Befehl verwendet,
svn copy. Jedoch würden Sie auch verwenden Sie den Befehl kopieren Sie eine Datei in den Kofferraum; es gibt nichts besonderes. Und es gibt nichts wirklich besonderes an Zweige oder tags, entweder. Sie sind nur normale Verzeichnisse, in die wir uns entschieden haben, speziell zu behandeln (und Sie kann sogar erzwingen, dass über Haken) zu erleichtern Projektverwaltung.svnnicht werfen nicht alle Fehler? Es ist rein der Entwickler, sollten Sie behandeln das, was es ist evisaged/ definieren , richtig?Mir, was ein Tag ist machen Sie eine Notiz, rev 712 war die version 1.
Ist es auch sehr einfach, um alle builds, Meilensteine, releases, etc., einfach durch einen Blick auf die Tags-Ordner.
Wenn man bedenkt, wie Etiketten arbeitete in der VSS-Tags sind viel schneller und einfacher, mit zu arbeiten, aber das gleiche erreichen. Nur nicht über analysieren, die Tatsache, dass es aus dem copy-Befehl nur wie ein Zweig.
Edit: Wenn Sie paranoid sind, über jemanden zu Begehen, änderungen an einem Tag-Ordner, den Sie verwenden konnten, pre-commit-hooks zu verhindern, dass es durch den Benutzer.
Aber in diesem Fall, müssen Sie einen expliziten Hinweis, speichern, dass der Hinweis irgendwo in einem Ort, wo jeder kann es sehen und es zu suchen.
Ist es viel einfacher, nur einen tag erstellen von revision 712 (dh, kopieren von r712 den tag-Verzeichnis) mit dem Namen "version 1-release". Und jeder sofort weiß, dass dies ist die Version, ohne zuerst zu schauen, welche revision der version 1-release war.
Eines subversion-repository ist nur ein einziger Baum von Dateien und Ordner, wo Sie können jeden Teil des Baumes zu jeder version seiner Geschichte zu jeder Zeit.
Wie schon andere gesagt haben tags/branches/trunk ist alles nur eine Konvention oben auf, dass, subversion erlaubt Ihnen, kopieren Sie einen Teil des Baumes, um woanders für (fast)kostenlos, aber im Kern, das ist es.
Du hast Recht, dass Sie einen stabilen Zweig für Ihre version. Die tag fungiert als name für eine bestimmte version geschickt irgendwo extern - und der commit Kommentar wenn Sie erstellen das tag gibt Ihnen die chance, zu erklären, wo es ging und warum (zB "public beta release", "um Kommentare").
Gibt es mehrere hook-Skripte gibt, die verhindern, dass Sie änderungen an einem tag, aber Sie werden nicht standardmäßig implementiert, da einige Leute verwenden Sie subversion in einer vollständig anderen Weise (zB config Datei-backup, etc). Subversion ist ein generisches Werkzeug, es gibt keinen "richtigen" Weg, es zu benutzen, nur starke Konventionen, die für Allgemeine Situationen.
In der Tat, collabnet beginnen zu überlegen, wie die Versionskontrolle verwendet wird, für nicht-Entwicklung Projekte. Die ganze Idee des tags der Stamm und die Zweige kann irrelevant sein, für einige dieser.
Meine Konvention, wenn man über ein Quellcode-repository ist:
Tags können auch geben Sie eine brauchbare url für die Dokumentation, z.B.:
"Die Veröffentlichung ist verfügbar unter http://svnserver/myproject/tags/1.0"
Könnte es sein:
"Die Veröffentlichung ist verfügbar unter http://svnserver/myproject/trunk@4483"
Aber wenn Sie Browsen durch das repository, wirst du nie kommen über @4483 und wissen, dass es in irgendeiner Weise besonders.
Wir benutzt, um tag-spezifische builds, die waren interessant, aber nicht freigibt, z.B.: "Investor Demo", etc.
Tags sind nicht dazu gedacht, verändert zu werden, sollten Sie einen Zweig, wenn Sie das tun wollen.
Können Sie einen Zweig von einem tag, das ist wahrscheinlich das, was Sie würde tun wollen, dann wieder tag, die Ergebnisse, die Verzweigung als eine andere version.
Sollten Sie nicht in der Kasse ein tag für die Bearbeitung.
Verlieren Sie nicht die Geschichte von Verzweigungen(kopieren) im SVN. Es ist alles miteinander verbunden.
Tags sollen Referenz unveränderlich "- version der Anwendung" einer Reihe von Dateien.
("version der Anwendung" im Gegensatz zu "technische interne Versionsnummer verwendet, die durch den VCS", wie die revision für den SVN, oder SHA-1 für Git, oder die id für ClearCase, oder...)
Sie sollen dienen als Referenz abgefragt werden und der Einsatz in einem anderen Arbeitsbereich (zum testen oder UAT - User Acceptance Tests -)
Seit SVN implementiert tags Filialen: als Verzeichnis der Anreiz zum ändern der Dateien in einem tag stark sein kann, aber würde Niederlage der Zweck eines Tags. Andere VCS, hat der Begriff label (oder "baseline"), die, einmal festgelegt, können nicht mehr verschoben.
Denen Georg Mauer Kommentare:
"implementiert" ? Aber das Taten Sie nicht "implementiert," die Vorstellung vom tag. SVN hat keine "tag" - per se. Sie einfach wiederverwendet werden Ihre äste und sagte, es könnte auch verwendet werden als ein tag.
SVN RedBook klar:
Ich einen tag erstellen jedes mal, wenn ich fördern ein Projekt von einem Entwicklungsserver auf einen Produktions-server. Das gibt mir die Geschichte von dem, was code wurde gefördert, um die Produktion. Wenn es Probleme gibt, kann ich schnell ein Rollback auf die frühere Produktion version.
Würden Sie auch nicht zur Kasse/ändern/übertragen alles, was in den tags-Verzeichnis. Es ist einfach ein Ort, um einen Schnappschuss von Ihrem code ab einem bestimmten Punkt in der Zeit.
Meiner Erfahrung-tags verwendet werden für die release-Marker, und wo Sie wahrscheinlich nicht, um änderungen vorzunehmen.
Wenn Sie erstellen eine "release2-0-Zweig", und dann änderungen vornehmen müssen (z.B. um einen Fehler zu beheben gefunden, der post-launch) ist es nicht mehr das repräsentiert, was Sie veröffentlicht-version 2.0.
Wenn Sie stattdessen die "release2-0" - tag und finden, die Sie benötigen, um den patch, die version, die Sie erstellen können eine neue Niederlassung, die machen das Update da, und der tag, der als "release-2-0-1".
Diese Weise können Sie leicht Zugriff auf Ihre Freigaben.