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?

[Phoenix]

Immer ein komplettes Projekt in dem jeweiligen Zustand.

Man checkt immer nur einen Ordner aus. Also z.B: MeinProjekt\Trunk.

Man hat normalerweise nie Trunk, Branches und Tags gleichzeitig auf der platte. Wäre ja auch doof, denn unter Tags 'Tagged' man normalerweise ein Release. Man hätte also jedes jemals erstellte Release der Software parallel auf der Platte.

In Branch stecken entwicklungszweige, die man z.B. auch mal nicht kompilierfähig einchecken kann, ohne dass es andere Stört.

Beispiel:

MeinGroßesProjekt\Trunk - hier entwickeln alle an der aktuellen Version
MeinGroßesProjekt\Branches\NeuesFeature - hier wird ein neues Feature entwickelt, dass erst in den Trunk kommen soll wenn es fertig ist
MeinGroßesProjekt\Branches\UmbauFachklassen - hier wird etwas entwickelt, was zwangsläufig mal einen nicht kompilierfähigen stand erzeugt. Das kommt erst in den trunk wenn es fetrig ist.
MeinGroßesProjekt\Tags\1.1\ - Hier ist Version 1.1 drin
MeinGroßesProjekt\Tags\1.2\ - Hier Version 1.2
MeinGroßesProjekt\Tags\2.0\ - Hier Version 2...

[Dezipaitor]

Trunk ist der Hauptzweig der Entwicklung. Normal baut man hier neue Features usw. die nicht für die Produktion geeignet sind und viele Fehler haben können.

Branches enthält parallele Entwicklungen zum Trunk oder anderen Branches. Stelle es dir als Baum vor. Parallele Entwicklung kann z.B. für Releases verwendet werden. Man zweigt vom Trunk die Entwicklung ab, weil man sagt, dass nun die komplettierten Features nun getestet und verbessert werden sollen. Nach dem Release kann mann dann dort auch noch Fehler beheben.
Hat man mehrere Kunden für dasselbe Produkt mit jedoch leicht unterschiedlichen Konfigurationen, kann man so jeden Kunden mit seinem massgeschneiderten Produkt beliefern, während im Trunk neue Features entstehen.

Tags enthalten Schnappschüsse vom Trunk, Branches oder Teilen davon. Sie sind im Gegensatz zu Branches fix und können/dürfen nicht verändert werden. Es sind einfach Zustandssituationen zu bestimmten Versionen. SVN vergibt zwar für jede Änderung eine eindeutige Revision, d.h. man bräuchte Tags garnicht, jedoch kann man Tags mit Namen benennen.
In SVN ist es (leider) möglich, auch Tags weiter zu verändern und somit als Branch zu missbrauchen.

[alias5000]

Ein kleiner Nebenhinweis zu diesem sehr interessanten Artikel:
Es ist möglich, in SVN Pfadbasierte Berechtigungen zu setzen: http://www.delphi-forum.de/viewtopic.php?p=519508

Gruß
alias5000

[BenBE]

Zitat:

Zitat von 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.

Diese Aussage ist falsch, siehe http://svnbook.red-bean.com/nightly/...d.authz.perdir

Das kan auch svnserve, man muss es nur entsprechend einrichten. Wobei der Weg über den Apache eindeutig der flexiblere ist ;-)

vgl. Crossposting in EE: http://www.delphi-forum.de/viewtopic...&postorder=asc

[RWarnecke]

Da ich alleine Programmiere ist das unerheblich mit den Zugriffsrechten. Ich habe eigentlich noch zwei Verständnisfragen.

Ich habe mir Arbeitskopien erstellt von einem Linux Server. Was passiert, wenn ich jetzt diese Arbeitskopie auf einen Windows Server mit Commit überspiele und dann wieder später auf meinen Linux Server ? Oder sollte ich da ganz die Finger von lassen ?

Ich habe mir mal die Größe der Repositories angeschaut. Die ist ja um ein vielfaches kleiner als meine Arbeitskopie, wird das ganze durch die Datenbank soweit runterkomprimiert ?

[BenBE]

Du solltest sicherstellen, dass Du in deiner Arbeitskopie für jegliche Text-Files, deren Zeilenenden unter Windows und Linux verschiedenen sind (Also jeglicher Source, Textfiles, ...) das SVN-Property svn:eol-style mit dem Wert native haben. Dann gibt es da eigentlich wenig Probleme

[RWarnecke]

Hallo Benny,

Zitat:

Zitat von BenBE

Du solltest sicherstellen, dass Du in deiner Arbeitskopie für jegliche Text-Files, deren Zeilenenden unter Windows und Linux verschiedenen sind (Also jeglicher Source, Textfiles, ...) das SVN-Property svn:eol-style mit dem Wert native haben. Dann gibt es da eigentlich wenig Probleme

wo stelle ich denn das SVN-Property ein ? Ist das eine Datei auf dem Server oder kann ich da auch über Tortoise gehen ?