Programmplanung. Blueprint. Wie geht ihr vor? Hilfsmittel?

[snafu]

Was sind denn für euch die wesentlichen Unterschiede zwischen Git und Mercurial?

[DasIch]

Git hat Github, brauchbare Branches und ein paar komplizierte Funktionen die sowieso keiner versteht. Mercurial hat Bitbucket ist in Python geschrieben(einfach erweiterbar) und läuft auch unter Windows absolut problemlos.

[Pekh]

Hallo!

Gibt es irgendwo eine deutschsprachige Anleitung/Tutorial oder ein Buch das Mercurial erklärt? Denn auf Englisch habe ich kaum eine Chance, das System dahinter zu verstehen.

lg
Gerold

http://mercurial.selenic.com/wiki/Germa ... gMercurial

- keine Ahnung, wie gut die Übersetzung ist. Prinzipiell habe ich in der Bedienung aber keine großartigen Unterschiede zu Subversion in Erinnerung.

[snafu]

Git hat Github, brauchbare Branches und ein paar komplizierte Funktionen die sowieso keiner versteht. Mercurial hat Bitbucket ist in Python geschrieben(einfach erweiterbar) und läuft auch unter Windows absolut problemlos.

Kannst du vielleicht ein bißchen ins Detail gehen? Windows-Unterstützung ist schon mal gut. Meistens brauche ich zwar kein Windows, aber zum Testen eines "plattformunabhängigen"* Moduls, wäre es ja ganz nett, auch ein Repo auf meiner XP-Partition zu haben. Das mit Python ist mir eigentlich egal, da ich nicht denke, was an Bitbucket ändern zu wollen.

Prinzipiell habe ich in der Bedienung [von Mercurial] aber keine großartigen Unterschiede zu Subversion in Erinnerung.

So wie ich es verstanden habe, unterstützt SVN nicht direkt das Taggen von Versionsständen. Das geht da nur über Kopien in vorher angelegte Verzeichnisse, was ich blöd finde.
_______________

* Natürlich ist "plattformunabhängig" relativ, wenn man etwas gerade mal für zwei verschiedene Systeme testet.

[Pekh]

Naja, ich hab zuerst die Bekanntschaft mit Hg gemacht. Mein anschließender Ausflug zu Subversion fiel dann sehr kurz aus, so daß ich die Feinheiten von Subversion wahrscheinlich nie zu Gesicht bekommen habe. Gibt bestimmt auch Sachen, die dort angenehmer geregelt sind.

[jbs]

Hab mir gestern http://chaosradio.ccc.de/cre130.html angehört und empfehle das auf jeden Fall weiter. Git ist unter anderem in der Bourne Shell geschrieben, was es dementsprechend kompliziert macht für Windows (cygwin). Da ist hg mit python einfacher.

Kann man nicht auch mit hg/git in ein svn repo pushen?

[BlackJack]

@snafu: Dein Kommentar zum erweitern von Bitbucket legt ein Missverständnis nahe: Mercurial *selbst* ist (zum Grossteil) in Python geschrieben. Selbst wenn Du Mercurial nicht selber erweitern möchtest, gibt es Plugins die Du vielleicht verwenden willst, und die sind halt auch in Python geschrieben.

Warum findest Du das Taggen bei SVN blöd? Kopieren bedeutet da ja nicht, dass die Daten wirklich kopiert werden, es werden nur "Links" auf den Stand einer bestimmten Version angelegt. Das geht also schnell und braucht kaum zusätzlichen Speicher. Geschwindigkeit und Speicherverbrauch (auf Platte) hängen nur von der Anzahl der Dateien ab, nicht von deren Grösse.

@gerold: Ganz grob vereinfacht hast Du die Funktionen von SVN die auf dem lokalen Repository arbeiten was sozusagen im Arbeitsverzeichnis enthalten ist. `update` und `commit` beziehen sich also auf dieses Repository und nicht auf ein entferntes auf einem Server. Um mit dem zu kommunizieren gibt es `push` und `pull` um die ganzen lokalen Commits in das entfernte Repository zu "pushen", oder Änderungen die dort von anderen "gepusht" wurden, in das eigene lokale Repository zu "pullen" und dann mit einem `merge` mit dem lokalen Entwicklungsstand zu verschmelzen.

Das entfernte Repository hat im Gegensatz zu SVN-Repositories aber keine Sonderrolle, sondern ist gleichwertig zum Lokalen. Was bedeutet man kann im Grunde beliebig zwischen Repositories/Arbeitskopien Änderungen mit `push` und `pull` austauschen. Was dann zu anderen Arbeitsabläufen als bei SVN führt.

Zum Beispiel braucht ein Maintainer keine `commit`- bzw. in diesem Fall `push`-Rechte an Fremde vergeben. Er kann das Haupt-Repo für jeden zum Lesen, also Klonen, freigeben und jemand der Änderungen durchführt kann das machen und seinerseits das Repo mit den Änderungen zum Lesen für jeden freigeben. Der Maintainer kann dann bei diesem Repo die Änderungen anfragen, und wenn ihm gefällt was er da sieht, kann er sie ganz einfach ins Haupt-Repo "pullen".

Branches wurden angesprochen: Mercurial's Unterstützung für Branches innerhalb eines Repos sind relativ neu und rudimentär. Der übliche Weg zu "branchen" ist es einfach das Repo zu klonen, die Entwicklung dort durchzuführen und am Ende die Änderungen wieder in das "Trunk"-Repo zu "pushen".

[lunar]

@snafu: Die Unterschiede sind nicht kolossal, und das meiste, was man so hört, betrifft vor allem alte Versionen von Git und Mercurial, insbesondere die Punkte Branching und Windows-Unterstützung.

Git unterstützt Windows mittlerweile ebenso vernünftig wie die meisten anderen DVCS, es gibt einen nativen Port, TortoiseGit und iirc sogar ein VS-Plugin. Mercurial dagegen hat mittlerweile Branches, die für die tägliche Arbeit durchaus brauchbar sind, obwohl ihnen ein paar der mächtigeren Features von Git fehlen, aber wie oft braucht man "git rebase" schon ...

Was Git dagegen wirklich hervorhebt, ist der Index (aka staging area). Er macht die Bedienung von Git schwerer und umständlicher, erhöht die Flexibilität aber ungemein. Wenn man den Index mag, ist Git ohne Alternative, wenn man ihn nicht mag, dann ist Git nicht besser als Mercurial.

Ich persönlich nutze beide DVCS, und ziehe Git eben wegen des Index und der besseren SVN-Unterstützung vor. Den Hype um Github kann ich allerdings nicht nachvollziehen. Im Vergleich zu Bitbucket finde ich Github ziemlich arm, insbesondere der Issue Tracker ist eigentlich schon ziemlich unbrauchbar, dazu kommen viele kleine Ärgernisse.

Was wirklich für Git spräche, wäre gitorios, weil diese Seiten projektzentriert ist und einen zentralisierten Arbeitslauf abbildet. Damit ist sie für große Projekte, die nicht von Einzelpersonen, sondern von großen Teams oder gar Firmen getragen werden, besser geeignet.

@jbs: Für die Anbindung an SVN gibt es git-svn und hgsubversion.

@BlackJack: Es sind eben keine echten Tags, sondern nur durch Kopien emulierte Tags. Das System sieht in diesen Kopien nichts besonderes. Das ist eine Ursache für die Schwierigkeiten, die Subversion beim verzweigter Entwicklung hat.

[jens]

Wäre IMHO mal eine gute Idee, alle Daten/Fakten zu den Systemen im wiki fest zu halten.

Wobei es das natürlich schon gibt:
http://versioncontrolblog.com/compariso ... index.html
http://www.infoq.com/articles/dvcs-guide
in deutsch:
http://de.whygitisbetterthanx.com/

[snafu]

Was Git dagegen wirklich hervorhebt, ist der Index (aka staging area). Er macht die Bedienung von Git schwerer und umständlicher, erhöht die Flexibilität aber ungemein. Wenn man den Index mag, ist Git ohne Alternative, wenn man ihn nicht mag, dann ist Git nicht besser als Mercurial.

Die Staging Area ist im Wesentlichen der Schritt des Bekanntmachens (add) neu angelegter Dateien, damit diese bei den Commits berücksichtigt werden, so dass es möglich wird, Dateien anzulegen, die später nicht ins Repo übertragen werden sollen, eben indem man `add` weglässt, richtig?

[lunar]

@snafu: Nein, das wäre ja nichts besonders (hg add gibt es schließlich auch). Die Staging Area enthält nicht Dateien, die committed werden sollen, sondern Änderungen. Ich kann jetzt schwer erklären, wie sich das auf den Arbeitsablauf auswirkt, ich denke, man erkennt den Nutzen des Features erst, wenn man es einmal selbst ausprobiert hat.

Allerdings kommt man auch prima ohne aus.

[BlackJack]

Mal 'ne Frage zur "staging area": Ich kenne das so, dass man von Kollegen Schläge bekommt, wenn man etwas commited was nicht kompiliert oder Laufzeitfehler verursacht. Wie stelle ich das denn sicher wenn ich von meinen Änderungen nur Teile commite? Lokal testen kann ich's ja nicht!?

[ms4py]

Hab mir gestern http://chaosradio.ccc.de/cre130.html angehört und empfehle das auf jeden Fall weiter. Git ist unter anderem in der Bourne Shell geschrieben, was es dementsprechend kompliziert macht für Windows (cygwin). Da ist hg mit python einfacher.

Mit msysgit http://code.google.com/p/msysgit/ und TortoiseGit http://code.google.com/p/tortoisegit/ lässt sich Git auch problemlos unter Windows verwenden.

[Dauerbaustelle]

Git hat brauchbare Submodules. Mit Mercurial "Forest" ging bei uns dauernd alles kaputt. Ich weiss allerdings nicht, wie das heute ist, der Forest-Versuch ist so etwa ein halbes Jahr her...

[jens]

Wie brauchbar sind die Git/Mercurial addons für eclipse/aptana?

[lunar]

@BlackJack: Grundsätzlich kann man Änderungen außerhalb des Index mit "git stash --keep-index" quasi beiseite legen, die Änderungen im Index anschließend testen, und zum Schluss die nicht indizierten Änderungen mit "git stash pop" wieder hervorholen.

Allerdings kommt der Index auch oft gerade dann zum Tragen, wenn man unzusammenhängende Änderungen hat, weil einem beispielsweise beim Implementieren eines Features in der Dokumentation einer anderen Funktion Fehler entdeckt hat. Diese Fehler kann man dann an Ort und Stelle korrigieren, und trotzdem im Commit außen vor lassen, damit man in der Historie nur in sich geschlossene und atomare Änderungen hat.

Das Problem, dass man nur die Änderungen im Index testen muss/möchte, stellt sich daher nicht immer.

[Leonidas]

Warum findest Du das Taggen bei SVN blöd?

Also als ich von CVS zu SVN gekommen bin dachte ich mir: Mensch, super Sache, sowas. Aber im Alltag ist das branchen und taggen eben irgendwie recht viel Handarbeit mit kopieren und schauen dass die Pfade stimmen. Letztendlich hat sich eh die trunk/tags/branches-Struktur durchgesetzt, wäre schön wenn SVN das irgendwann mal auch out of the box könnte. Zudem checkt mann bei SVN dann meist nur Trunk aus denn obwohl Tags und Branches billige Kopien auf dem Server sind, sind sie es nicht bei auschecken und auch nicht auf der Festplatte (ich lasse mich aber eines besseren belehren wenn mir jemand sagt dass so ein Checkout Hardlinks nutzt).

Das begegnet mir bei der Arbeit mit SVN öfter: gute Ideen, die in der Theorie gut gedacht sind, aber in der Praxis sich nicht so bewähren (Cheap Copies, WebDAV).

[jens]

Eigentlich könnte man, bei dieser Diskussion, noch gleich einen Vergleich zwischen http://github.com/ , http://bitbucket.org/ , google code und sourceforge einbeziehen

Wobei mich github <-> bitbucket <-> google code interessieren würde.

Früher hab es viele neuen Django Projekte bei google code. Aktuell scheint sich das alles zu verteilen. Auf allen drei Plattformen gibt es eine menge:
http://code.google.com/intl/de-DE/query/#q=django
http://bitbucket.org/repo/all?name=django
http://github.com/search?q=django

[Dauerbaustelle]

Google Code hat halt kein Social-Features und dazu noch unglaublich schlecht designed. Google hat das Talent, Minimalismus mit schlechter Farbwahl und lieblosem Design gleichzusetzen. (Google Mail ist da eine Ausnahme.)

[jens]

Also sourceforge und google code kenne ich, dort hab ich eigene Projekte.

Kann jemand was zu den Unterschieden zwischen github und bitbucket sagen?