Wenn prüfe ich in einem SVN-Repo-STAMM vs FULL PROJECT aus?

Question

Got a (hoffentlich kleine) Frage SVN in Bezug auf und repos Check-out. Grundsätzlich sehe ich Tutorials und Vorschläge in Konflikt in Bezug auf was zu überprüfen, und wann. Einige werden sagen:

svn co http://my.repos.com/project my_project

... während andere sagen:

svn co http://my.repos.com/project/trunk my_project

Wann würde ich möchte gegen das gesamte Projekt den Stamm direkt greifen? In der Vergangenheit habe ich noch nie Probleme mit entweder hatte, aber ich bin nicht sicher, ob es gibt Situationen, in denen man besser, die andere ist.

Best.

Answer 1

Es gibt ein paar andere Punkte zu beachten darüber.

1. Der tags Baum (und es wird in der Regel ein Baum sein) enthält hypothetisch unveränderliche Schnappschüsse des Codes zu einem bestimmten Zeitpunkt; das ist nicht etwas, das Sie ändern möchten, da die meisten Implementierungen werden auf Tags basieren
2. Die meisten Subversion Clients beschweren, wenn Sie versuchen, Änderungen in dem tags Baum zu begehen, anstatt nur das Kopieren in dem
3. Für die meisten Zwecke ist trunk ein Sonderfall der Verzeichnisse unter branches; der einzige wesentliche Unterschied besteht darin, dass es die Hauptentwicklungspfad
enthalten wird erwartet,

Es ist in der Regel keinen guten Grund, das gesamte Projekt zu überprüfen, wie andere haben darauf hingewiesen, wie die meiste Zeit Sie arbeiten nur auf dem Stamm und ein oder zwei Zweige, und das gesamte Projekt kann eine erhebliche Menge davon essen Festplattenplatz. Die wichtigste Entwicklung „Zweig“ ist meist das einzige, was Sie brauchen.

Hier ist ein reales Beispiel. Unser Team macht alle Code-Änderungen an den Stamm. Wenn wir eine Alpha (pre-complete) Release benötigen, markieren wir nur den Kofferraum. Nachdem wir für eine bestimmte Veröffentlichung „Code complete“ getroffen, erstellen wir einen Code Freeze Zweig, in dem wir alle unsere Versionsänderungen tun. Die Beta, RC und GA-Releases werden von diesem Zweig markiert. Wenn wir eine GA-Version patchen müssen, wird der Patch gegen den Zweig getan und mit dem Stamm zusammengeführt. Auf diese Weise haben wir nicht über neueren Code Sorge in die geprüft und zugelassen GA undicht, wenn wir Patch etwas Bestimmtes brauchen. Es erlaubt uns auch so schnell arbeiten an der nächsten Version der Software zu starten, wie der Code ist gesperrt.

Auch wenn es ein „Nebenprojekt“ ist die Out-of-Band ist für den Stamm, können Sie einen Zweig für das Erstellen und führen Sie sie, wenn Sie bereit sind.

Wie einige Teams für jeden Fehler einen Zweig zu erstellen, und einige Arbeiten direkt am Stamm (wie bei mir). Wenn Ihr Team den Bug-per-Zweig der Fall ist, würde ich nie das ganze Projekt überprüfen. Unter anderem würde ich eine ganze Menge Code sehen würde ich nicht kümmern uns um.

Auch nur ein Punkt über das Repository-Management, wie durch @humble_coder erwähnt - die meisten Subversion-Tools sind ziemlich einfach zu bedienen, wenn es um Zweig / Tag-Management kommt. Zum Beispiel hat TortoiseSVN einen Repository Browser, Dinge zu kopieren um ermöglicht (Branches und Tags erstellen) ziemlich leicht, und auch das SVN-Kommandozeilen-Tool kann verwendet werden, um die gleiche Sache wie eine atomare Operation zu tun (wir haben tatsächlich ein Skript das schafft entweder die alpha-Tags, den Code-Freeze Zweig oder die Post-Gefrier-Release-Tags).

Hope, das hilft!

Answer 2

in der Regel ein Subversion-Repository hat 3 Hauptverzeichnisse:

1. Zweige
2. Tags
3. Stamm

Trunk ist für die meisten up to date Zweig des Codes.

Branchen sind in der Regel erstellt, um eine bestimmte Funktion zu entwickeln, dass Sie noch nicht im Kofferraum werden sollen.

Stichworte sind wie save-Punkte des Rumpfes.

Wenn Sie eine Kasse an der Wurzel des Projekts zu tun, werden Sie alle Zweige bekommen, alle Tags und den Kofferraum. Dies kann zu einer großen Menge an Daten führen.

Wenn zum Beispiel jeder Ausgabe des Codes markiert ist, werden Sie den Quellcode aus Ihren früheren Versionen erhalten!

Ich hoffe, dies wird Ihnen helfen,

Jerome Wagner

Answer 3

Es hängt davon ab, wie Sie Ihre Repository Layout zu tun, aber in der Regel werden Sie diese Struktur haben:

/trunk
/tags
/branches

Innerhalb beide tags und branches, können Sie mehrere Kopien des Projekts (je wieder auf wie verwenden Sie das Repository).

Wenn Ihr Repository wird auf diese Weise angelegt, und Sie / Kasse, werden Sie mit mehreren Kopien des Codes (Tags und Zweigen) enden, dass man nicht annehmen kann, rührend sein (Tags, zum Beispiel).

Wenn Sie stattdessen /trunk Kasse, werden Sie nur die Version überprüfen Sie aktuell arbeiten, das ist, was Sie in der Regel wollen.

Answer 4

Ich würde nie das gesamte Projekt der Kasse. Normalerweise bin ich nur in einem Zweig zu einem Zeitpunkt interessiert, vielleicht zwei, gelegentlich drei. Ich habe Stamm immer ausgecheckt und aktualisiert. Wenn ich den Betrieb einer freigesetzten Markierung (vielleicht für Bug-Untersuchung) überprüfen, muß ich es überprüfen, untersuchen und löschen. Zweige unter branches gespeichert typischerweise eine viel kürzere Aufmerksamkeitsspanne haben, das heißt, sie erstellt werden und fieberhaft für eine kurze Zeit verwendet und dann nie wieder berührt.