Ich habe eine Mischung aus kleinen und großen Projekten in SVN. Einige von ihnen sind so klein, dass ich mich nicht verzweigen oder markieren kann.
Also, sollte ich noch bei der trunk / trunk / tag Folder Convention bleiben, auch wenn ich ziemlich sicher bin, dass die branch / tag Verzeichnisse für die kleineren Projekte nicht verwendet werden? Ich habe einfach das Gefühl, es könnte übertrieben sein.
Gedanken dazu?
Um die Frage in Ihrem Titel direkt zu beantworten: Nein, das müssen Sie nicht. SVN-Repositories können in jeder von Ihnen gewählten Ordnerstruktur organisiert werden.
Nachdem dies gesagt wurde, ist es wahrscheinlich eine gute Idee, zumindest alles in einen Stammordner zu legen, damit Sie, wenn Sie später Ihre Meinung ändern und entscheiden, dass Verzweigen oder Markieren nützlich ist, Verzweigungs- / Tag-Ordner hinzufügen können leicht, ohne alles herumbewegen zu müssen.
Ich benutze die branch / tag / trunk Verzeichnisse in Subversion auch für triviale Projekte. Es ist so gut wie null Kosten und ist es in Konsistenz wert. Ich weiß immer, wie mein Projekt angelegt wird, wenn ich jemals einen Checkout machen muss.
Sie sind Konvention, also was tut es weh, sie hinzuzufügen. Wenn Ihr Projekt an den Punkt kommt, an dem Sie es benötigen, ist es viel einfacher, sie von Anfang an zu verwenden, als sie nachher hinzuzufügen.
In meinem SVN-Repository habe ich ein einziges trunk / branch / tag Verzeichnis. Ich lege alle meine Projekte in den Stamm und organisiere meine Zweig- und Tag-Verzeichnisse getrennt basierend auf den Projekten, die tatsächlich einen Taggable-Zustand erreichen. Convention schlägt möglicherweise vor, für jedes Projekt ein Zweig- / Tag- / Stammverzeichnis zu verwenden. Dies kann jedoch unpraktisch sein, wenn Sie nicht erwarten, dass es markiert und verzweigt wird.
Sogar persönliche Projekte können von häufigen Markierungen und Verzweigungen profitieren, bevor größere Umschreibungen vorgenommen werden oder nach einer langen Pause.
Normalerweise (oder ganz offensichtlich) sind Verzweigungen / Markierungen in Teams sehr nützlich, wo viele Programmierer gleichzeitig mit der Quelle arbeiten. Jeder Coder arbeitet in seinem eigenen Zweig, so dass kein Risiko besteht, über die Arbeit eines anderen zu sparen.
Als One-Man-Army-Entwickler habe ich das Branching / Tagging immer noch nützlich gefunden, wenn:
Ich muss einen experimentellen Zweig machen, ohne auf die aktuelle Arbeitsquelle zu verzichten. Ich werde es wieder zusammenführen, wenn der experimentelle Code besser ist.
Wenn ich mehrere separate Komponenten habe, kann es nützlich sein, jede mit einem Namen zu versehen, der die Projektversionsnummer angibt, und sie in einen Tag-Ordner zu platzieren, der nach dem Projekt benannt ist. Dies hilft Ihnen, Tabs zu behalten, wenn Sie zu Version 1.0.5.10 zurückkehren möchten und wissen müssen, was sich in der Komponente Foo geändert hat. Die Commit-Notizen sind möglicherweise nicht aussagekräftig genug.
Nach meiner Erfahrung ist die Organisation "trunk / branch / tag" ein ziemlich gut benutztes Layout für die Quellcodeverwaltung. Ich habe gesehen, dass es in verschiedenen Organisationen implementiert wurde, die verschiedene Tools verwenden (ClearCase, SVN, CVS, um nur einige zu nennen). Das ClearCase-Setup, mit dem ich derzeit arbeite, ist etwas ausgeklügelter (verschachtelt?), Folgt aber im Allgemeinen einem sehr ähnlichen Layout.
Obwohl es in SVN nicht benötigt wird, würde ich sehr empfehlen, sich an diese Art von Layout zu gewöhnen, einschließlich der Verschmelzung zu / von verschiedenen Zweigen und dem Stamm.
Für persönliche Projekte halte ich das Tagging für ein wertvolles Mittel, um endgültige, unveränderliche Releases zu erhalten. Zweige sind typischerweise für experimentelle Tangenten reserviert, so dass ich die neueste (stabile) Version meines Codes nicht zerstören werde, bevor die Realität einsetzt.
Tags und Links svn