Sinnvolle Ordnerstruktur für mehrere Projekte in Subversion

[RWarnecke]

Hallo zusammen,

da ich nun so langsam mit Subversion zurecht komme. Bin aber noch nicht perfekt. Wollte ich mal um eure Meinung fragen, wie Ihr eine entsprechende Struktur für mehrere Projekte in Subversion aufbauen würdet ?

[Dezipaitor]

Ich kenne nur zwei Arten:

Code:

tags
branches
trunk
  |- Projekt_1
  |- Projekt_2
  ...

Code:

Projekt_1
  tags
  branches
  trunk
Projekt_1
  tags
  branches
  trunk
...

[RWarnecke]

Hallo Christian,

die zweite Variante kenne ich aus einer Beschreibung, wobei mir die erste Variante für sinnvoller erscheint. Jetzt bleibt für mich eigentlich nur noch die Frage, zu welchem Zeitpunkt lege ich ein neues Repository an oder lege ich nur ein einziges Mal ein Repository an ?

[Luckie]

Für was sind den eigentlich die einzelnen Zweige gedacht?

[Dezipaitor]

Zitat:

Zitat von RWarnecke

Jetzt bleibt für mich eigentlich nur noch die Frage, zu welchem Zeitpunkt lege ich ein neues Repository an oder lege ich nur ein einziges Mal ein Repository an ?

Man legt neue Repositories normalerweise dann an, wenn sich die Zugriffsverhältnisse ändern. Also wenn bei einem neuen Projekt andere Mitarbeiter dabei sind und nicht jeder darauf Zugriff haben soll. Bei SVN kann man nämlich nicht den Inhalt eines Repository einzeln mit Zugriffsrechten beschränken.

@Luckie: Sry, die Frage verstehe ich nicht.

[OregonGhost]

Zitat:

die zweite Variante kenne ich aus einer Beschreibung, wobei mir die erste Variante für sinnvoller erscheint.

Wo liegt der Sinn bei der oben genannten Variante 1? Da muss man ja immer alle Projekte kopieren, wenn man branchen oder taggen will.

Bei uns ist ausschließlich Variante 2 im Einsatz. Jedes Projekt wird einzeln behandelt und hat eigene Tags, Branches und nen Trunk. Alles andere ist in meinen Augen nicht sinnvoll.

Was die Repositorys angeht, hier ist man recht frei. Bei uns wird das so gehandhabt: Es gibt pro Kunde ein Repository (und dann noch eins für interne Entwicklungen). Das funktioniert recht gut, beruht im Endeffekt aber darauf, dass die Anzahl unserer Kunden relativ begrenzt ist, während gleichzeitig die Anzahl der Projekte pro Kunde relativ hoch ist. Insofern kann man das nicht verallgemeinern.

[RWarnecke]

Zitat:

Zitat von Luckie

Für was sind den eigentlich die einzelnen Zweige gedacht?

Hallo Michael,

hiermal ein Zitat aus einer Anleitung :

Zitat:

Es gibt ein paar empfohlene Standards um die Daten innerhalb eines Projektarchivs zu organisieren.
Die meisten Leute erstellen einen trunk Ordner, der den „Stamm der Entwicklung“ enthält, einen
branches Ordner, welcher Entwicklungszweige enthält und einen tags Ordner, der markierte
Zustände enthält. Wenn ein Projektarchiv nur ein einziges Projekt enthält ist die folgende Struktur zu
empfehlen:
/trunk
/branches
/tags

[Dezipaitor]

Die Anleitung ist aus der Tortoise SVN Hilfe und lässt sich vollständig so lesen:

Zitat:

4.1.5. Repository Layout
Before you import your data into the repository you should first think about how you want to organize your data. If you use one of the recommended layouts you will later have it much easier.

There are some standard, recommended ways to organize a repository. Most people create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:

/trunk
/branches
/tags

If a repository contains multiple projects, people often index their layout by branch:

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc

...or by project:

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Indexing by project makes sense if the projects are not closely related and each one is checked out individually. For related projects where you may want to check out all projects in one go, or where the projects are all tied together in a single distribution package, it is often better to index by branch. This way you have only one trunk to checkout, and the relationships between the sub-projects is more easily visible.

If you adopt a top level /trunk /tags /branches approach, there is nothing to say that you have to copy the entire trunk for every branch and tag, and in some ways this structure offers the most flexibility.

For unrelated projects you may prefer to use separate repositories. When you commit changes, it is the revision number of the whole repository which changes, not the revision number of the project. Having 2 unrelated projects share a repository can mean large gaps in the revision numbers. The Subversion and TortoiseSVN projects appear at the same host address, but are completely separate repositories allowing independent development, and no confusion over build numbers.

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, TortoiseSVN can move or rename them however you wish.

Switching from one layout to another is just a matter of issuing a series of server-side moves; If you don't like the way things are organized in the repository, just juggle the directories around.

[OregonGhost]

Ach ja, was ich bei meiner Lösung noch ergänzen sollte: Mit "Projekt" ist hier eine komplette Projektstruktur gemeint. Bei VS-Projekten also zumeist die komplette Solution mit allen enthaltenen Projekten, und das sind dann also "related projects". Man ist ja recht frei, wie man das genau handhaben will und insofern sehe ich erst recht wenig Sinn in Variante 1, weil ich da der TortoiseSVN-Bedingung "and each one is checked out individually" folgen würde. Also den "Bruch" immer dort machen, wo man separat auschecken möchte.

[Luckie]

Ich wollte wissen, was in die Ordner reinkommt. Also was kommt in die Ordner trunk, branches und tags?