Versionskontrolle

[veers]

Da sieht man wieder, wie man sich von Idolen beeinflussen lassen kann.

Es gibt Anwendungsgebiete in denen SVN besser ist und es gibt Anwendungsgebiete in denen GIT besser ist. Einfach ein System pauschal zu verteufeln halte ich nicht für sinnvoll.

Linus verteufelt auch Gnome und diverse andere Dinge. Das gehört wohl zu ihm Aber er hat schon seine legitimen Punkte.

oder Subversion wenn man closed source zeug macht, für open source Projekte find ichs mittlerweile einfach nur eine schlechte Idee, da hat Linus' Präsentation geholfen. Ansonsten ist git einen Blick wert, da tut sich momentan viel.

Grundsätzlich bin ich da mit Blackbirds Aussage einverstanden.

[welterde]

http://www.opensolaris.org/os/community ... /bzr-eval/

Local clone of this repository: 23m02s - 25m31s over three runs.
Local commit of one file in the repository: 16m47s.

Das ist nicht langsam, das ist unbrauchbar!

http://www.opensolaris.org/os/community ... -final.txt

Local clone of the same repository: 2m35s
Local commit of one file in the repository: 9s

Wobei zumindest als das getestet wurde Git kein (funktionierendes/history erhaltendes) mv hatte.

Werde mir Mercurial wohl doch noch ansehen.

version 0.7?
das ist URALT(aktuell ist 0.16)
schau dir das mal an http://bazaar-vcs.org/Performance/0.15
außerdem reden wir von __kleinen__ projekten, nicht von super-großen

[N317V]

Durch seine Bestimmung als "zentralisiertes System" ist es dafür halt prädestiniert (na, wer erkennt den Pleonasmus?).

Durch seine Bestimmung ist es vorbestimmt. Nettes Argument. Bist Du Manager, Politiker oder im Marketing?

[tiax]

Nein, ich studiere Germanistik und bediene mich dadurch dann doch gern mal einer Tautologie

[Panke]

Vielleicht hätte ich dazuschreiben sollen, dass es bei mir auf dem Arbeitsrechner laufen soll (und der fährt linux) und max. zwei Personen an kleinen Projekten arbeiten. Dabei brauch ich nur Unterstützung für reine Textfiles.

Ich schätze ich schau mir erstmal Subversion an.

[mitsuhiko]

http://www.youtube.com/watch?v=4XpnKHJAok8

Da sieht man wieder, wie man sich von Idolen beeinflussen lassen kann.

Linus ist kein Idol. Wäre er das würde ich KDE und GIT nutzen.

Es gibt Anwendungsgebiete in denen SVN besser ist und es gibt Anwendungsgebiete in denen GIT besser ist.

Das habe ich doch vorhin geschrieben:

Subversion wenn man closed source zeug macht

Ich denke für closed source Entwicklung ist Subversion durchaus brauchbar.

Einfach ein System pauschal zu verteufeln halte ich nicht für sinnvoll.

Das habe ich auch nicht getan.

Ich kann nur soviel sagen: Momentan geht mir Subversion unglaublich auf den Sack weil ich einen Branch in einem Branch bräuchte da viele lokale Veränderungen. Lösung: birkenfeld hat den trunk gelockt, damit da keiner Änderungen machen kann, das könnte sonst keiner mehr mergen.

Auch die Sache mit dem Commit Rechten ist nervig. Wäre viel praktischer, wenn jeder einen Checkout machen kann und seinen Branch veröffentlicht. Wenn die Änderungen von dem Gut sind kann ich die einfach pullen. Kein nerviges Commit Rechte austauschen.

[gerold]

Hallo blackbird!

Linus ist kein Idol. Wäre er das würde ich KDE und GIT nutzen.

Sorry!

Subversion wenn man closed source zeug macht

Ich denke für closed source Entwicklung ist Subversion durchaus brauchbar.

Auch Open Source Programme lassen sich wahrscheinlich gut mit Subversion entwickeln. Wie ich schon schrieb, denke ich, dass viele viele Open Source Programme von nicht viel mehr als 2 oder drei Leuten entwickelt werden. Diese Leute können sich gut untereinander absprechen, so dass das einfach zu verwendende Subversion sicher keine schlechte Wahl ist.

birkenfeld hat den trunk gelockt, damit da keiner Änderungen machen kann, das könnte sonst keiner mehr mergen.

Ich spreche mich mit meinen Kollegen ab. Wenn einer seinen Branch ins Trunk mergen möchte/muss/soll, dann wird während dieser Zeit der Trunk gesperrt. Damit meine ich eigentlich, dass alle Kollegen eine Nachricht bekommen, dass am Trunk nichts geändert werden darf, bis ich wieder das OK dazu gebe. (Locks gibt es ja noch nicht so lange.) Das ist für mich die einfachste Lösung. Branches oder auch Teilbereiche des Trunk werden von uns selbständig gesperrt.

Kein nerviges Commit Rechte austauschen.

Das gibt es bei uns nicht. Jeder hat alle Rechte im Repository. Ändert jemand etwas, dann bekommen alle ein Email mit den Änderungen zugeschickt. Das ist genug Kontrolle für mich.
Ändert jemand etwas ohne meine Erlaubnis, dann wird die Änderung rückgängig gemacht und der Verursacher zusammengeschissen.

Das was Zeit braucht, ist das Mergen eines Branches in den Trunk-Ordner. Aber wie könnte man so etwas vereinfachen? Hat Git dafür ein besseres Rezept? Im Video spricht Linus meist von Teilen des Repositories (SCSI, USB, Network,...), das er (weil er Vertrauen in seine Top-Leute hat) komplett übernehmen kann. Bei mir sind es aber Änderungen an EINEM Programm und selten an irgendwelchen Unterprogrammen.

Ich bestimme, wer in welchem Teilbereich des Programmes etwas ändern darf. Ich erwarte mir von meinen Kollegen vor einer Änderung Hinweise darauf, was diese wo ändern möchten. Will oder muss jemand etwas ändern, was sich im Quellcode an sehr vielen Stellen niederschlägt, dann wird dafür ein neuer Branch erstellt.
Mit diesen Informationen, mit der Aufteilung in Branches, mit Locking (gibt es ja noch nicht lange) und meiner Arbeitsverteilung konnte ich große Merge-Aktionen bis jetzt ziemlich gut vermeiden.

Aber eines muss ich zugeben. Viel größer dürfte das Team nicht mehr werden. Dann müsste ich mehr Zeit in die Verwaltung stecken. Ich denke mal, dass sich bei größeren Projektgruppen die Einarbeitung in Git sicher rentiert.

lg
Gerold

[Sr4l]

http://better-scm.berlios.de/comparison/comparison.html

[veers]

http://better-scm.berlios.de/comparison/comparison.html

Da fehlen git und bazaar

[Sr4l]

dafür sieht man wie Visual SourceSafe abkackt
immer nur ein No oder Not directly

[veers]

dafür sieht man wie Visual SourceSafe abkackt
immer nur ein No oder Not directly

Naja eigentlich müsste SourceSafe ja Datei Versionsverwaltung für mutige Masochisten heissen
Weil mit Safe hat das nichts zu tun

[birkenfeld]

Kein nerviges Commit Rechte austauschen.

Das gibt es bei uns nicht. Jeder hat alle Rechte im Repository. Ändert jemand etwas, dann bekommen alle ein Email mit den Änderungen zugeschickt. Das ist genug Kontrolle für mich.
Ändert jemand etwas ohne meine Erlaubnis, dann wird die Änderung rückgängig gemacht und der Verursacher zusammengeschissen.

Abgesehen davon, dass man in SVN AFAIK gar keine ACLs definieren kann (man kann Beschränkungen nur unschön über pre-commit Hooks machen), geht um diese Situation: Jemand außerhalb deines Teams möchte an deinem Programm Änderungen machen, also seinen eigenen Branch haben und darin Versionskontrolle, ohne dass er Zugriffsrechte auf das Original-Repository hat oder braucht.

[gerold]

Jemand außerhalb deines Teams möchte an deinem Programm Änderungen machen, also seinen eigenen Branch haben und darin Versionskontrolle, ohne dass er Zugriffsrechte auf das Original-Repository hat oder braucht.

Hallo birkenfeld!

Das http://svnbook.red-bean.com/nightly/en/ ... authz.html gibt's noch nicht lange.

lg
Gerold

[birkenfeld]

Trotzdem heißt das, dass *du* jedes Mal Arbeit hast, wenn jemand in dem Repository arbeiten will.

Mit verteilten Systemen zieht sich jeder seinen Branch, ohne dass du dich darum kümmern musst, und ohne dass jemand dein Repository vollmüllt.

[lunar]

Ich verwende git, und würde es ohne Zögern empfehlen. Es ist sehr schnell, einfach zu benutzen, es gibt ein paar schöne Programme zur Visualisierung der Entwicklungszweige in einem Repo, und es kennt viele Wege, über die man pushen und pullen kann. Dadurch kann man ein zentrales git-Repo nahezu überall aufsetzen (z.B. auch im Webspace von Sourceforge oder BerliOS Projekten, auf den man dann anonymen Zugriff per http und Entwicklerzugriff per ssh erhält).

Allerdings muss man wahrscheinlich auch sagen, dass zwischen Mercurial, bzr und git im täglichen Einsatz (vor allem bei kleinen Projekten mit kleinen Teams) nur sehr wenig Unterschied besteht.

Auf subversion (bzw. zentrale SCMs allgemein) würde ich nach Möglichkeit verzichten... imho zwingt subversion zu einem sehr zentralisierten und hierarchischem Entwicklungsprozess. Besonders wenn man keine vollständigen Rechte im Repo hat, oder nur untergeordneter Entwickler ist, dann kann man nicht so einfach eine neue Branch anlegen, um z.B. ein bisschen mit bestimmten Codeteilen zu experimentieren.

Bei git dagegen kann man ohne Probleme lokale branches anlegen, die erstmal kein anderer sieht. Diese braucht man auch nur bei bestehendem Interesse für andere offenzulegen. Man kann also "mal eben schnell" ein bisschen experimentieren, ohne gleich auf dem zentralen Server was zu ändern. Das erleichtert auch externen Entwicklern die Arbeit... sie können einfach eine Kopie des Repos holen, darin ihren Code schreiben, Patches erzeugen und diese per Mail an die Hauptentwickler schicken, welche sie dann in das zentrale Repo integrieren. Diese Änderungen reflektieren sich beim externen Entwickler durch ein erneutes Pull. Bei subversion dagegen muss man dagegen erstmal aus der lokalen Kopie ein lokales Repo erzeugen, um vernünftig zu entwickeln, wenn man keine Rechte auf dem Server hat.

Außerdem hat man bei dezentralen Repos zwangsläufig immer ein backup parat, für den Fall, dass der Server mal crasht.

[Leonidas]

Ich selbst nutze Subversion, wie man ab und zu in meinen Posts sieht über WebDAV. Was aber auch ziemlich langsam ist, das muss man zugeben.
Daneben nutze ich Bazaar seit Version 0.13 und inzwischen in Version 0.16. Das lag daran, dass Mercurial damals noch ``move`` nicht als Move sondern als ``Copy + Delete`` implementiert hat. Ist inzwischen vermutlich anders geworden.

Ja, Bazaar ist langsam, und ja, es ist gehyped. Wenn zwar nicht so wie Ubuntu, aber ein wenig schon. Aber ich muss zugeben, ich kann damit gut arbeiten und es macht durchaus Spaß. Die Bediehnung des Tools ist ziemlich intuitiv, es funktioniert problemlos etc. Und die Zeit die bazaar braucht, steht sowieso nicht im Verhältnis zu der Zeit die ich zum programmieren brauche.

Was ich besonders dran schätze ist eben die wirklich brauchbare Bediehnung und auch die Möglichkeits commit zurückzuziehen. Werde aber in Zukunft schauen, dass ich Git ausprobiere und vielleicht mal wieder Mercurial ansehe.

Fest steht: ich würde keines der Systeme als schlecht ansehen. Darüber hinaus hann man alle drei Systeme auch zentralisiert benutzen... ist doch kein Problem?