Versionskontrolle

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

welterde hat geschrieben:
birkenfeld hat geschrieben:Ja, ich stehe damit auch ganz allein da.
*böses unterstell* es gibt ja auch leute, die finden M$ gut :roll:
oder linux schlecht *noch böseres unterstell*
aber davon fangen wir besser nicht an
Da fehlt mir jetzt der Zusammenhang.
birkenfeld hat geschrieben:Wenn du C nicht magst, solltest du Python allerdings nicht mehr einsetzen.
ach, jetzt auch noch python schlecht machen.... *schlimm, schlimm* ;)
Non sequitur.
aber anstatt, die jeweils anderen VCS durch den Kakao zu ziehen, sollten wir besser die coolen features, der jeweiligen vcs hervorheben, nich?
Dann fang besser mal an.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

blackbird hat geschrieben:für open source Projekte find ichs mittlerweile einfach nur eine schlechte Idee, da hat Linus' Präsentation geholfen.
Hallo blackbird!

Du sprichst in Rätseln. Welche Präsentation? So viele Projekte mit mehr als 10 gleichzeitigen Mitarbeitern gibt es jetzt auch wieder nicht. Warum gegen Subversion??? Ich arbeite im Durchschnitt mit 2-4 Personen an Projekten, die in SVN-Repositories liegen. Dabei bin ich aber immer die letzte Instanz. Ich bin für den Code verantwortlich und gebe die Regeln vor. Ich denke mal, dass bei den meisten Projekten eine oder zwei Personen die oberste Instanz dar stellen, die die Regeln vorgeben und anderen Entwicklern ihren eigenen Branch für Teilprojekte zuweisen und letztendlich auch das OK für die Einbindung eines Branches in den Trunk geben.

SVN ist unter Windows sehr gut in den Explorer integriert und mit pySVN-Workbench http://pysvn.tigris.org/docs/WorkBench.html gibt es auch einen GUI-Client, der angeblich nicht schlecht sein soll. Mit den Hooks, können serverseitig z.B. beim "Commiten" des Quellcodes Programme ausgeführt werden. Ich nutze das z.B. um Websites und Intranetsites von Kunden lokal zu entwickeln. Der neueste Tag stellt die Website dar, die automatisch aktualisiert wird. Das funktioniert sogar mit Zope, wenn man im Dateisystem entwickelt.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

gerold hat geschrieben:Du sprichst in Rätseln. Welche Präsentation? So viele Projekte mit mehr als 10 gleichzeitigen Mitarbeitern gibt es jetzt auch wieder nicht. Warum gegen Subversion??? Ich arbeite im Durchschnitt mit 2-4 Personen an Projekten, die in SVN-Repositories liegen. Dabei bin ich aber immer die letzte Instanz. Ich bin für den Code verantwortlich und gebe die Regeln vor. Ich denke mal, dass bei den meisten Projekten eine oder zwei Personen die oberste Instanz dar stellen, die die Regeln vorgeben und anderen Entwicklern ihren eigenen Branch für Teilprojekte zuweisen und letztendlich auch das OK für die Einbindung eines Branches in den Trunk geben.
http://www.youtube.com/watch?v=4XpnKHJAok8

Anschauen, das erklärt auch die Frage :D
TUFKAB – the user formerly known as blackbird
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

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.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

gerold hat geschrieben: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.
blackbird hat geschrieben: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
User
Beiträge: 5
Registriert: Mittwoch 15. November 2006, 17:29

veers hat geschrieben: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
Proud to be a [url=http://www.pocoo.org/]Pocoo[/url] Developer.
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

tiax hat geschrieben: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? :twisted:
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Nein, ich studiere Germanistik und bediene mich dadurch dann doch gern mal einer Tautologie
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Panke
User
Beiträge: 185
Registriert: Sonntag 18. März 2007, 19:26

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
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

gerold hat geschrieben:
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:
blackbird hat 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.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Hallo blackbird!
blackbird hat geschrieben:Linus ist kein Idol. Wäre er das würde ich KDE und GIT nutzen.
Sorry!
blackbird hat geschrieben:
blackbird hat geschrieben: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.
blackbird hat geschrieben: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.
blackbird hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Da fehlen git und bazaar :(
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

dafür sieht man wie Visual SourceSafe abkackt ;-)
immer nur ein No oder Not directly ;-)
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Sr4l hat geschrieben: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 :)
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

gerold hat geschrieben:
blackbird hat geschrieben: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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

birkenfeld hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
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.
Antworten