Thema: Source-Verwaltung

[hannibal]

hallo,

ich hab mir grad gedacht, man sollte sich auch ein system ueberlegen, wie man die sources verwaltet; d.h. einerseits brauchen wir eine ordnerstruktur, und andrerseits brauchen wir ein system zum verwalten der sources an sich.

wie is denn das mit cvs und svn und was weiss ich was es da noch gibt?

(oder hab ich vielleicht mal wieder was verpasst und das ganze ist schon besprochen worden? )

lg, hannibal

[mastermesh]

Ne Ordnerstruktur gibts schon. Kann ich dir gerne zukommen lassen.

[hannibal]

das waer fein =)

[Another Stupid Coder]

Ich wäre für SVN

[Jidder]

<-- pro SVN

[The-Programmerfish]

harhar und woher nehmt ihr nen SVN Server?

(Stillschweigender Protest für CVS - Braucht man zwar auch nen Server aber ist mir sympathischer)

[mastermesh]

Kann hier jemand für die Nichtwisser unter uns (/me ist so einer) erklären, wo die wichtigsten Unterschiede zwischen CVS und SVN liegen?

[stultus]

ich würd mich über aufklärung in dieser hinsicht auch freuen. und wegen server, wenns nen normales programm is was unter debian (linux) läuft, sollt sich da was einrichten lassen (keine garantie, aber anzunehmen das ich erlaubnis bekomme)

[The-Programmerfish]

Ich könnt au nen Serveer einrichten der CounterStrike Funclan bei dem ich bin hat nen Root Server da hat jeder von den Membern Admin Rechte und darf AFAIK alles drauf machen was er will ^^

[stultus]

JEDER adminrechte? Ach du Schande, da gabs noch keinen Ärger?

[joachim_neu]

hm... vielleicht kann mal jemand erklären, was genau das überhaupt is asc hat mir nurmal gesagt, dass es zur verwaltung der sourcen is. aber kann man des net auch einfach per PHP und MySQL machen?

[stultus]

zu SVN kann ich rein garnix sagen, zu CVS schon etwas mehr
1) Enthält eine Benutzerverwaltung
2) Speichert jede Version jeder Datei und spuckt dir auf eine Anweisung sofort alles aus was zu ner bestimmten Version gehört
3) Wenn 2 die Gleiche Datei bearbeiten (aber nicht an der Gleichen Zeile was machen was zu nem Konflikt führt) erkennt das CVS die Änderungen und fügt sie dementsprechend ein (wenn also 2x in alten kopien an unterschiedlichen stellen nen paar zeilen eingefügt werden, werden die änderungen von beiden Dateien nach möglichkeit eingebaut ohne andere Änderungen die sich nicht in der lokalen Kopie des Programmierers befanden zu überschreiben. Kann aber auch zu Konflikten führen, die müssen dann vom Progger selbst gelöst werden)
Beispiel(e) für Einsatzgebiete: Sourceforge Komplett

und zur Frage ob man das mit PHP & Mysql machen könnte: Theoretisch ja, wäre aber sehr viel Verwaltungsaufwand und manche einstellungen wie MAX_EXECUTION_TIME könnten die sache nicht grade erleichtern ^^

[The-Programmerfish]

JEDER adminrechte? Ach du Schande, da gabs noch keinen Ärger?

Noch nicht weil wir den Server noch nicht haben ^^ Wir sind nur zu 8. und wir kennen uns schon länger aus dem deutschen Purebasic Forum und derjenige der den Server bestellt hat vertraut uns scheinbar soweit dass wir keinen Mist machen ^^

[stultus]

PB Forum? Wer denn so (evtl kenn ich ja noch einen )?

[The-Programmerfish]

Lukaso, MVXA (früher littelfurz), 125, Laurin, orange-blue, hardfalcon und the one and only (<- ich)

[Jidder]

Vorteile von Subversion gegenüber CVS

• In Subversion können Dateien (und Verzeichnisse) auch umbenannt und verschoben werden. In CVS muss eine Datei an der alten Stelle auf "Gelöscht" gesetzt und an der neuen Stelle neu eingefügt werden, wobei die Historie der Datei nicht übernommen wird.
• Subversion kann auch Verzeichnisse und Dateiberechtigungen (rwx) verwalten.
• Subversion bietet einen verbesserten Umgang mit Binärdaten. Es erkennt binäre Dateien (beispielsweise Bilder oder Audiodateien) automatisch und es werden (wie bei Textdateien) nur die Differenzen zwischen den geänderten Versionen gespeichert. In CVS geht das umständlicher über Eintrag von binären Dateitypen (deren Endung) in cvswrappers und wobei diese Filetypen voll gespeichert werden.
• Commits sind in Subversion atomar, weshalb eine Änderung entweder komplett oder gar nicht ins Repository gespeichert wird. Verbindungsabbrüche und mehrere, gleichzeitige Commits können somit nicht zu inkonsistenten Zuständen führen.
• Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien, sondern auf das ganze Repository. Bei jedem Commit erhöht sich die Revisionsnummer aller Dateien. Somit kann man einfacher eine exakte Version beschreiben (z. B. "Version 2841" statt "Version vom 23. März 2004 20:56:31 GMT"), allerdings bedeutet dies auch, dass sich zwei Revisionen einer Datei nicht unbedingt unterscheiden müssen.
• Zusätzlich zu einem eigenen Server und der Speicherung im lokalen Dateisystem existiert auch ein Modul für den Apache 2 Webserver, mit dem die Daten auch mit der HTTP/HTTPS-Erweiterung WebDAV übertragen werden können.
• Einige Operationen (update, tagging, branching) sind deutlich schneller als bei CVS.
• Manche Operationen, welche bei CVS Zugriff auf das Repository benötigen, kommen bei Subversion ohne einen solchen Zugriff aus, da eine Kopie der BASE-Revision innerhalb des Arbeitsverzeichnisses gespeichert wird. Dadurch entfällt bei Remote-Repositories die Notwendigkeit eines Netzwerk-Zugriffs.
[/list:u]

Nachteile gegenüber CVS

• Die gleichen Daten (z. B. nach Konvertierung) benötigen in einem Subversion-Repository deutlich mehr Platz als in einem CVS-Repository.
• Da im Arbeitsverzeichnis eine Kopie der BASE-Revision gehalten wird, benötigen Arbeitsverzeichnisse ungefähr den doppelten Platz.
• Subversion ist noch nicht so gut getestet wie CVS.
• Benötigt den Apache HTTP Server 2.0, wenn das WebDAV-Feature genutzt werden soll. Allerdings könnte man hier entgegnen, dass CVS WebDAV gar nicht unterstützt. Außerdem gibt es auch ein eigenes Protokoll, welches vergleichbar mit dem Netzwerkprotokoll von CVS ist.
[/list:u]

Quelle

Viele der Punkte hätte ich auch selber nennen können, aber wozu gibt es die Wikipedia? Wirklich Interessierte hätten zunächst mal eine Suchmaschine oder Wikipedia befragt

[stultus]

Wie läufts hier nu, hat man sich schon auf etwas geeinigt? Sollte man ja langsam machen, wenn das kernelteam bald mit coding anfangen will...