Mit Stamm / Äste und Tag-Struktur zwischen mehreren Entwicklern

Question

Ich am Ende immer verwirrt, wenn es um Trunk / Branches und Tags.Folgende ist meine Abfrage:

Wir haben ein team von Entwicklern arbeitet an einem Projekt.Die Entwickler sind oft in Gruppen unterteilt und Sie arbeiten auf verschiedene Module auf der gleichen Projekt.

Derzeit haben wir einen einfachen SVN-system (ohne Trunk / Branches oder Tags), wo jeder arbeitet auf die gleiche lokale server und verpflichtet den Dateien.Aber das problem beginnt, wenn ein paar Entwickler die Arbeit an der Zukunft-Module (die sollen nicht gehen sofort live).In dieser situation können Sie nicht verpflichten, die Daten, denn wenn Sie es tun, Ihre Entwicklung wird der code hochgeladen auf dem live-server und es wird am Ende vermasselt alles.

So, nun bin ich auf der Suche nach irgendeiner Art von Lösung, wenn diese Entwickler können separat arbeiten, aber auf dem gleichen code.So etwas wie dieses:

Entwickler arbeitet an Neuen Modul Eine Entwickler B arbeitet an Neuen Modul B Entwickler C arbeitet auf Bug-Fixes von Modul C (die bereits auf Leben, aber auch einige bugs, die behoben werden muss)

So, die Entwickler haben es ist eigenen Kopie, die auf diese Maschine und verpflichten sich, dem Entwickler das repository.(Zweig)

Die gleiche Logik gilt für Entwickler B-Entwickler C arbeiten werden auf eine gemeinsame stabile Exemplar, das irgendwo in den Tags und sobald die Arbeit ist getan, es wird markiert und schob den Stamm für das hochladen auf die live-server.

Sobald Entwickler Eine ist fertig mit der Arbeit, er will push all seine Dateien, die auf-Trunk für live hochladen.(Dies sollte Zusammenführen einige gemeinsame Dateien im Kofferraum zu).Dieselbe Logik gilt auch für Developer B.

Ich bin nicht sicher, ob SVN werden die richtige Lösung für diese oder nicht.Ich weiß nicht einmal wissen, ob es eine einfachere Art und Weise zu implementieren, was ich will.

Jede Art von Anregungen sind willkommen.

Vielen Dank TTR

Answer 1

Meiner Meinung nach ist meine Meinung, dass Sie, wenn alle Ihre Entwickler an getrennten Projekten arbeiten, Zweigstellen beseitigen können. Es kann eine kleine Organisation dauern (z. B. richtige Protokoll -Kommentare und Versioning), aber das kann viel weniger problematisch sein als Verzweigungen und Verschmelzung.

OK, aber wenn Sie Zweige wollen, sind sie einfach. Es gibt mehrere Ansätze, aber im Grunde genommen beinhalten alle eine "Master" -Version, bei der der endgültige Code endet. Dies kann Kofferraum sein, oder einige Leute bevorzugen es, Änderungen am Kofferraum vorzunehmen und dann den Code zu verschmelzen, um Filialen zu veröffentlichen. Der „Stamm ist Meister“ ist jedoch das einfachste Konzept, das zu verstehen ist.

In SVN ist es einfach, eine Niederlassung zu machen - es ist eine billige Kopie. Ihr einziges Problem ist, ein Verzeichnis mit den Dingen zu füllen (ich empfehle, eine Filiale zu löschen, sobald Sie damit fertig sind). SVN gibt Ihnen auch eine besondere Art von Zweig für diese Art von Arbeit - die Reintegrationszweig. Es ist etwas Besonderes, da SVN verfolgt, was mit ihm passiert, es ist so gestaltet, dass Sie einen Zweig aus dem Kofferraum erstellen, daran arbeiten, ihn gelegentlich mit Änderungen aktualisieren, die an Trunk vorgenommen wurden, und dann alle Ihre Arbeiten an diesem Zweig in einen Kofferraum wieder integrieren. Final Bang. Dann können Sie von vorne anfangen. Es klingt so, als könnte dies das sein, was Sie wollen - normalerweise hätten Sie keine Zweigstelle pro Entwickler, Sie hätten eine Filiale für jedes Arbeitspaket.

Das Problem mit Per-Dev-Zweigen ist, dass die Änderungen, die sie vornehmen, als immer länger ein Zweig lebt, immer schwieriger zu verschmelzen. Dies gilt insbesondere dann, wenn die Entwickler die Arbeit des anderen Entwicklers nicht regelmäßig in ihre Zweige verschmelzen (wie sie es gewohnt sind).

Da SVN billige Kopien macht, würde ich wahrscheinlich empfehlen, den gesamten Kofferraum für jeden Entwickler zu verzweigen. Ich finde, dass es einfacher ist, sich daran zu erinnern, dass anstatt einzelne Verzeichnisse zu verzweigen, und Sie immer in der Lage sind, gemeinsame oder gemeinsame Dateien zu ändern, ohne sich Sorgen zu machen, wenn Sie sie begehen, wenn sie eine andere Niederlassung brechen. (dh, wenn Sie Branche/Kofferraum/Modulea und später feststellen, dass Sie sich ändern müssen/koffer/einschließen/common_file, dann befindet sich die gemeinsame Datei nicht in Ihrer Filiale, da Sie einen Untereinsatz verzweigen. Also verzweigen Sie also nur am Wurzel. Ich kostet dich zusätzlich)

Answer 2

In Ihrer Frage, Sie haben gerade ausgedrückt der Grund hinter dem ganzen trunk/tags/branches Modell - es ist für die Verwaltung der genau diese situation, das ist eine normale situation für eine Entwicklung, Online-shop, um in die nach kurzer Zeit.

Eine Sache, die Planung der migration von einer trunkless Modell, um ein Stamm-Modell.

Sie sagen, Sie haben keinen trunk, tags, branches, etc.Also ich nehme an, Ihr Modell so aussieht:

/
 filea.html
 fileb.html
 dira/
  filex

Ein Wort der Warnung - versuchen Sie nicht, Filiale root-Verzeichnis unter sich.

zB:

svn cp / /branchA

Das Ergebnis wäre ein Verzeichnis, das wie folgt aussieht:

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

Unpicking was ist ein Teil der root-Zweig und der sub-Zweige wird ziemlich hartnäckigen ziemlich schnell.

Halten Sie es sauber - bewegen Sie den code in Kofferraum zuerst.Dies ist die Art von strukturellen springen, die verlangen, dass jeder (und alle Ihre deployment-Systeme), um zu löschen Sie Ihre Arbeitsbereiche und bekommen alles sauber aus:

svn cp / /trunk

Jetzt Sie können Ihre Niederlassungen:

svn cp /trunk /branches/branchA

Geben Sie eine Struktur wie:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

Sobald die Zweige aus, die dev ' s können überprüfen Sie Sie heraus und arbeiten an Ihnen.Ihre deployment-system kann auf Stamm/ anstelle des root-Ordner und bereitstellen.

Jeder Entwickler arbeitet an Korrekturen können trunk.Wenn Sie sich verpflichten, die Bereitstellung system bereitgestellt werden Ihre änderungen, so wie Sie es jetzt tun.

Wenn branchA ist fertig, aber die Entwickler können merge die änderungen in trunk so wie gbjbaanb schlägt.

Just a quick heads-up, viel Glück mit ihm.