SVN: Effektive Projekt-Strukturen

Hi,

ich bin am überlegen, wie ich am Besten eine Projekte-Struktur in meinem SVN anlege, was auch möglichst Effektiv ist.

Ich hab mir sowas gedacht:

/release
        /projectABC
                   /<files...>
        /projectXYZ
                   /<files...>

/trunk
      /c++
          /projektABC
                     /<files...>
          /projectBCA
                     /<files...>
      /csharp
             /projectXYZ
                        /<files...>
             /projectYXZ
                        /<files...>

Doch bevor ich mich festlege, wollte ich mal Fragen wie es die erfahreneren User hier handhaben

Ich habe mehrere Programmiersprachen in denen ich mehrere Projekte entwickle, nun wie teile ich die am besten im SVN auf?

Viele liebe Grüße und ein schönes Wochenende,
Stefan25

Blue-Tiger

Ich wuerd fuer jedes Projekt ein eigenes Repo anlegen Das macht zwar ein Backup der gesamten Daten nicht ganz so einfach, aber ansonsten wird dein Repo schnell sehr gross. Meine Meinung. Ausserdem ists ganz angenehm, wenn du dein Projekt an andere weitergeben willst. Dann kannst du einfach sagen "hier hast du das Repo", dann hat er Sourcen & die ganze History, sollte er sie mal brauchen. Wuerd mich aber auch mal interessieren, wie andere das machen: ein zentrales Repo fuer alles oder mehrere.

Wenn du die SVN-Doku gelesen haettest, wuesstest du, dass ein Repo in der Regel 3 Grossbereiche hat: trunk, tags & branches. Trunk fuer den aktuellen HEAD, tags sind in etwa das, was du unter "releases" verstehst und branches sind.. na ja, branches halt.
Wenn du alles ins gleiche Repo tun willst, waer meine Empfehlung: auf oberster Ebene die Projekte, und darunter dann die 3 Verzeichnisse.

Die Einteilung nach Programmiersprachen hab ich (zur Zeit) zwar auch, aber die macht immer weniger Sinn. Irgendwann hast du zig Projekte, und musst dann ueberlegen "hab ich das Ding seinerzeit in C++ oder in C# geschrieben...".

sothis_

nimm git. im ernst, lege mehrere repos an, sprich für jedes projekt einzeln. falls (was im laufe der zeit auch 100%ig geschieht) du irgendwann sehr viele halbfertige, experimentelle und testprojekte hast, die du nicht mehr weiterentwickelst, kannst du jene später immer noch in einem 'garbage' repository zusammenführen.

edit, mmmhh mal wieder zu langsam

frenki

Für jedes Proejekt ein Repo. Dieses sieht bei mir momentan so aus (Tags und Branches sind in meinen Augen eh dasselbe, weswegen ich Tags für Schwachfug halte. Vielleicht habe ich die auch nur nicht richtig kapiert...).

branches
   releases
      2007 08
      2008_01
      2008_07
   feature
      4086 Cooles Feature A
      3853 Cooles Feature B
trunk

Unter Releases liegen die Release-Versionen. Diese sind für neue Features gesperrt, hier werden nur noch Bugfixes durchgeführt (so ist zumindest die Theorie. Wer sich mit Vertrieblern rumärgert weiss dass das nicht immer umsetzbar ist...)

Unter feature liegen Feature-Branches. Wenn ein Feature funktioniert und getestet ist, wird es zum Trunk gemerged.

Die Releases heissen so wie sie bei uns intern heissen (Halt Jahr und Monat). Die Feature-Branches sind die Ticket-Nummer aus unserem Bugtracker (der auch Feature-Wunsch-Sammlung ist) mit einer kurzen Beschreibung.

Wir haben für mehrere Projekte ein Repo, wenn diese Projekte zusammen hängen. Also wenn man z.B. mehrere Libs hat, und diese gemeinsam genutzt werden, ist es unsinnig jeweils ein Repo anzulegen (wo würde das bei z.B. Boost enden?).

Repo
+ trunk
  + src
    + proj1
    + proj2
  + doc
    + proj1
    + proj2
+ branch
  + src
    + proj1
      +branch1
+ tags
  + src
    + proj1
      + v1_0
      + v2_0

unterhalb von trunk, branch und tags kann man aber natürlich auch andere Verzeichnisse anlegen, das ist ja bei SVN egal, man ist da frei. Aber trunk, branch und tags sollte meiner Meinung nach mind. vorhanden sein, da es bei SVN gängige Praxis ist (wenn auch kein Zwang), und so sich jeder dort wenigstens wiederfindet.

sothis_

Bulli schrieb:

Wir haben für mehrere Projekte ein Repo, wenn diese Projekte zusammen hängen. Also wenn man z.B. mehrere Libs hat, und diese gemeinsam genutzt werden, ist es unsinnig jeweils ein Repo anzulegen (wo würde das bei z.B. Boost enden?).

ist es gerade nicht. dazu gibt es externals und bei git submodules. der vorteil ist, das ich im submodul änderungen durchführen kann und diese zum originalrepo des moduls pushen kann.

und wen interessiert git? es geh um SVN. und der threadersteller hat nach unseren SVN-Erfahrungen gefragt. mußt ja nicht mitlesen, wenn dir svn nicht in den kram passt.

sothis_

Bulli schrieb:

und wen interessiert git? es geh um SVN. und der threadersteller hat nach unseren SVN-Erfahrungen gefragt. mußt ja nicht mitlesen, wenn dir svn nicht in den kram passt.

deswegen habe ich auch die extrernals von svn erwähnt. wenn du rumpöbeln möchtest, tu das woanders.

frenki

In SVN gibt's auch Externals. Allerdings... Wir hatten boost mal als External eingebunden. Das war aber so dermassen Langsam, dass wir's schnell wieder aufgegeben haben...

Und ja, mit Projekt meine ich das, was Visual Studio als Solution bezeichnet. Für jedes Unterprojekt ein Repo fände ich dann auch etws übertrieben.

Hey!

Danke für die vielen Antworten, da hier so oft dazu geraten wurde, ein Repro pro Projekt, werd ichs wohl so machen, Danke euch!