Subversion do's and dont's

[Corelgott]

Hi @ all,

SubVersion ist ja an sich ein super Spielzeug! (Bis auf die Tatsache, dass das Apachemodul leider nur in einem Appache 2.0.x läuft; Nicht aber in einem 2.2.x; Das war etwas ungenau beschrieben)

Mein Problem ist bloß, dass ich bisher nur mit CVS gearbeitet habe und das auch eher semi-professionell war.

Also mal doof gefragt:

Wie betreibt man so etwas orgentlich?
Ist SVN als apache-mod besser als der stand-alone?
Wie benutzt man Repositories richtig? Ein rep pro Projekt? Ein rep viele "Unterordner" in dem Projekte sind?
Wie checkt man bei Subversion vernünftig eine Version aus? (Wie macht man einen release? Einfach einen Stand nehmen und das war es? Oo)

Was sollte man vermeiden!?
Auf was sollte man achten?!
Was habt ihr das für Erfahrungswerte gemacht?

Literatur ist auch gern willkommen... Solange diese nicht all zu Praxis-fern ist. Die Theorie habe ich mittlerweile durch. Nun ist die Praxis angesagt. Das mal das zum Test auf jedenfall selbst aufsetzen muss ist schon fast klar. Aber vor weg einen Horizont zu haben wäre super...

Thx im Voraus!

cya
Corelgott

[Sascha L]

Hi,

wir haben in der Firma für jedes Projekt ein eigenes Repository, welches wir dann ausschecken.

Man kann dann sogenannte Arbeitskopien, ich glaube "Brunches", erstellen. Sodass man immer eine Kopie hat, die funktioniert und eine, an der man arbeitet. So kann man sich nichts ausversehen kaputt machen.

Diesen Ordner kann man dann ja als Unterordner nehmen. Genauso wie man sich dann ein Release-Ordner macht bzw. erstellen lässt.

Ansonsten, was man beachten sollte:

- Zwischendurch immer mal wieder, während der Arbeit, die Zwischenstände übertragen.
- Wenn man z.B. am nächsten Tag neu anfängt, und auch zwischen durch andere am Projekt mitarbeiten, IMMER erst auf "Aktualisieren" gehen, damit man wieder den neuesten Stand auf dem PC hat und erst dann weiter arbeiten. So vermeidetet man die gröbsten Konflikte.

Mehr kann ich dir leider nicht sagen.

[Luckie]

Zitat von Sascha L:

- Zwischendurch immer mal wieder, während der Arbeit, die Zwischenstände übertragen.

Genau das würde ich nicht machen. Wenn dann nämlich ein Kollege auscheckt, dann hat er ja ein, zum Beispiel, halb fertiges Dokument auf seinem Rechner. Ich checke immer nur dann ein, wenn das Dokument einen sinnvollen Zwischensatnd erreicht hat.

[Corelgott]

Hey wunderbar!

Genau so habe ich mir das erhofft (@ antworten)
Was das regelmäßige auschecken angeht. In meinen vorherigen cvs-Projkten habe ich das auch so gehandhabt immer mal wieder...
Das war auch an sich ganz ok. Aber Den Fall den Lucky darstellt, ist meiner erfahrung nach auch erher der erstrebenswerte, braucht aber in der Praxis doch ein bisschen disziplin ^^

Ok also für jedes Prjekt ein Repository. Das ist doch mal ne Aussage... Oder hat da jemand nen anderen vorschlag?
(Mal so nebenbei: wir reden hier wenn überhaupt erst mal über 10 ~ 15 kleinere Projekte also nicht die riesen menge...)

Mir fällt da gerade noch ne weitere Frage ein:

Wie sieht das mit der Daten-Größe aus? (Klar ist immer abhängig von den Daten die das Projekt braucht ^^; Bilder etc.)
Aber was würdet Ihr sagen? Wie groß sind eure Repositories "über die zeit" geworden? Was muss man da erwarten?
1Gb auf ca. 1 Jahr? bei ca. 5 aktiven Projekten und 10 eher sparsamen... Oder wird das eher zu wenig sein... Oder gar viel zu viel?

thx Corelgott

[Sascha L]

Zitat von Luckie:

Zitat von Sascha L:

- Zwischendurch immer mal wieder, während der Arbeit, die Zwischenstände übertragen.

Genau das würde ich nicht machen. Wenn dann nämlich ein Kollege auscheckt, dann hat er ja ein, zum Beispiel, halb fertiges Dokument auf seinem Rechner. Ich checke immer nur dann ein, wenn das Dokument einen sinnvollen Zwischensatnd erreicht hat.

Das mein ich ja, sinnvolle Zwischenstände

Wobei es aber auch immer auf das Projekt drauf ankommt. Denn was machst du, wenn dein PC abstürzt und die Daten weg sind? Passiert so gut wie nie, aber sowas kann halt passieren, dafür nutzt man ja u.a. Subversion auch, damit man die Daten gesichert hat.

Es kommt also auch immer darauf an, wieviele am Projekt arbeiten. Wenn man der einzige ist, dann kann man schon alle 30min mal wieder den Stand hochladen, sofern sich was entscheidenes geändert hat. Man hat ja auch ne schöne Log-Funktion, wo man dann alles erwähnen kann, was sie geändert hat.

@CorelGott: Also ich glaube nicht, dass der Speicherverbrauch so hoch geht, das kommt aber natürlich auf das Projekt an. Wenn man viele Bilder, etc. hat, dann geht es schnell in die Höhe. Aber ansonsten hat man ja fast nur den Quellcode und die Runtime-Exe im Repository und die verbrauchen nicht viel, trotz History. Sind ja alles nur immer Kilobytes und bis da mal ein Gigabyte zusammen kommt...

[Phoenix]

Zitat von Sascha L:

@CorelGott: Also ich glaube nicht, dass der Speicherverbrauch so hoch geht, das kommt aber natürlich auf das Projekt an. Wenn man viele Bilder, etc. hat, dann geht es schnell in die Höhe. Aber ansonsten hat man ja fast nur den Quellcode und die Runtime-Exe im Repository und die verbrauchen nicht viel, trotz History. Sind ja alles nur immer Kilobytes und bis da mal ein Gigabyte zusammen kommt...

Imho haben Kompilate respektive Binaries nix im Repository zu suchen. Da sind die Quellen, und zu einem Auslieferungsstand gehört genau die Revision zum Buildzeitpunkt. Ergo ist die .exe jederzeit rekonstruierbar und muss nicht eingecheckt werden.

Sowas wäre btw. bei automatisieren Buildsystemen die z.B. komplett Scriptgesteuert sind auch etwas doof zu realisieren. Da hagelt es sonst immer massivst Konflikte.

[nailor]

die Begriffe klingen immer wieder klasse, aber
Einchecken ist das hochladen von der lokalen Sandbox auf das zentrale Repository
und
Auschecken entsprechend das runterladen vom Server.


Was das einchecken von Kompilaten angeht: Sicher nicht immer sinnvoll, aber bei älteren/alten Codes kann es durchaus vorkommen, dass man den Code nicht mehr vernünftig kompilieren kann, aber das Binary noch laufen würde. Das wird zwar nicht innerhalb von ein paar Wochen während der normalen Entwicklung der Fall sein, aber wenn man mal nen älternen Code wieder aufgreift, ist man manchmal froh drum, wenn man direkt starten (doppelklicken und ausfürhren) kann.


Ich weiß nicht genau warum, aber die Entwickler von #develop zum Beispiel nutzen keine automatische Versionierung (bzw. setzen zumindest einen Teil der Daten von Hand). Muss also doch zumindest ein paar Vorteile haben.