Programmplanung. Blueprint. Wie geht ihr vor? Hilfsmittel?

[mutetella]

Ok, ich hab' mich jetzt für Mercurial entschieden....

Nachdem ich bisher noch überhaupt nicht mit einer Versionskontrolle gearbeitet habe, hätte ich noch ein paar Verständnisfragen:

1. Mit 'hg branch' wird meine Arbeitskopie als Zweig markiert. Mit 'hg clone' erstelle ich einen Klon/eine Kopie des gesamten oder eines speziellen Repository. Ich verstehe den Unterschied nicht wirklich. Ohne jetzt eine haargenaue Anleitung zu benötigen, aber wie gehe ich denn vor, wenn ich vom aktuellen Stand aus einen Zweig eröffnen möchte?

2. Ich habe gerold's Vorschlag übernommen und mir Trac installiert. Um Programmfeatures zu definieren und diese dann Versionen und Komponenten zuzuordnen ist das eine prima Sache. Auch kann ich mir vorstellen, künftig nicht mehr so schnell den Faden zu verlieren, wenn man mal etwas länger nicht mehr bei der Sache war... Für Trac gibt es ja auch eine Mercurial-Unterstützung. Wie kann ich mir das konkret vorstellen, wenn ich z. B. ein Ticket abarbeite: An welcher Stelle kommt hier Mercurial ins Spiel? Wenn ich das Ticket erledigt habe, d. h. neue Programmfeatures fertiggestellt sind, dann mache ich in Mercurial einen commit und in Trac wird das Ticket als erledigt gekennzeichnet. Weshalb muss da eine Verbindung zwischen Trac und Mercurial bestehen?

3. Ähnlich mit der VIM-Unterstützung: Welchen Vorteil hat eine solche Verzahnung zwischen Editor und Mercurial?

Danke schon mal für Eure Unterstützung!!

Gruß
mutetella

[Pekh]

Ok, ich hab' mich jetzt für Mercurial entschieden....

Nachdem ich bisher noch überhaupt nicht mit einer Versionskontrolle gearbeitet habe, hätte ich noch ein paar Verständnisfragen:

1. Mit 'hg branch' wird meine Arbeitskopie als Zweig markiert. Mit 'hg clone' erstelle ich einen Klon/eine Kopie des gesamten oder eines speziellen Repository. Ich verstehe den Unterschied nicht wirklich. Ohne jetzt eine haargenaue Anleitung zu benötigen, aber wie gehe ich denn vor, wenn ich vom aktuellen Stand aus einen Zweig eröffnen möchte?

2. Ich habe gerold's Vorschlag übernommen und mir Trac installiert. Um Programmfeatures zu definieren und diese dann Versionen und Komponenten zuzuordnen ist das eine prima Sache. Auch kann ich mir vorstellen, künftig nicht mehr so schnell den Faden zu verlieren, wenn man mal etwas länger nicht mehr bei der Sache war... Für Trac gibt es ja auch eine Mercurial-Unterstützung. Wie kann ich mir das konkret vorstellen, wenn ich z. B. ein Ticket abarbeite: An welcher Stelle kommt hier Mercurial ins Spiel? Wenn ich das Ticket erledigt habe, d. h. neue Programmfeatures fertiggestellt sind, dann mache ich in Mercurial einen commit und in Trac wird das Ticket als erledigt gekennzeichnet. Weshalb muss da eine Verbindung zwischen Trac und Mercurial bestehen?

3. Ähnlich mit der VIM-Unterstützung: Welchen Vorteil hat eine solche Verzahnung zwischen Editor und Mercurial?

Danke schon mal für Eure Unterstützung!!

Gruß
mutetella

ad 1) Ich arbeite eigentlich immer mit 'hg clone'. Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander - ist auf Dauer eindeutiger.

ad 2) Von Hause aus mußt du nach einem Commit die Tickets manuell schließen. Es gibt auch Trigger, die dir das abnehmen wenn im Text eines Commits ein Hinweis auf die zu schließenden Tickets enthalten ist, aber ich war bislang zu faul, mir sowas einzurichten. Trac ist einfach als Informationszentrum interessant: Du hast deine Tickets, quasi als Aktionsliste, die du dir nach verschiedenen Kriterien sortieren und filtern lassen kannst. Wichtige Hinweise, Dokumentation kommen ins Wiki. Es ist alles an einem Ort. Die Verknüpfung mit Mercurial ist da einfach "konsequent weitergedacht": Der Code der aktuellen Hauptlinie ist dann halt auch in Trac sichtbar, und man kann leicht Bezug auf ihn nehmen, in dem man z.B. eine Revisionsnummer im Text verwendet. Diese funktioniert dann als Link zum entsprechenden Code.

ad 3) Das Vim-Plugin macht Mercurial einfach "leichter" erreichbar in dem es die Befehle in das Menu integriert. Da ich sowieso immer ein Terminal-Fenster daneben offen habe, brauche und verwende ich es nicht.

[mutetella]

Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander

Ist damit aber nicht der Vorteil einer Versionskontrolle, Dateien/Verzeichnisse nicht doppelt anlegen zu müssen, vergeudet?

[Pekh]

Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander

Ist damit aber nicht der Vorteil einer Versionskontrolle, Dateien/Verzeichnisse nicht doppelt anlegen zu müssen, vergeudet?

Nein. Du hast ja nur ein Verzeichnis für jeden Zweig, nicht für jede Version. Um das mal zu illustrieren: Ich habe ein Projekt, das ich an die Bedürfnisse verschiedener Kunden angepaßt habe. Die Grundfunktionalität ist zwar die gleiche, aber es gibt halt kleinere Unterschiede. Die Zahl der Commits, d.h. der sicherungswerten Zwischenstände geht in die Hunderte. Ohne Versionsverwaltung würde ich tatsächlich von jedem dieser Zwischenstände eine komplette Sicherungskopie machen. Bzw. nur noch von einigen ausgewählten. Wodurch aber auch die Möglichkeit verloren geht, sehr kleine Veränderungen zu bewahren. So habe ich für jeden Kunden ein vom Hauptrepo abgeleitetes Repository und durch die Versionsverwaltung auch die Möglichkeit, Änderungen, die alle Zweige betreffen, ohne großen Aufwand von einem Zweig auf die anderen zu verteilen.

[mutetella]

Ok, prinzipiell klar, nur, muss nicht jeder Zweig, um testbar zu bleiben, den kompletten Inhalt eines Programmes beinhalten? Zudem 'hg clone' ja auch die komplette Version eines Repository's kopiert. Konkret: Wenn ich ein Arbeitsverzeichnis mit 'a.py', 'b.py' und 'c.py' habe und darauf basierend einen Zweig mit 'hg clone' eröffne, erhalte ich wieder ein Arbeitsverzeichnis mit den 3 Dateien. Um in Deinem Bereich zu bleiben: Wenn Du für 5 Kunden 5 variierende Programme pflegst, dann beinhalten die 5 Zweige doch immer auch alle Dateien des Hauptprogrammes, selbst wenn Du bei einem Kunden z. B. nur Änderungen an 'b.py' vornimmst. Oder steh' ich jetzt total auf der Leitung...?

[veers]

Ok, ich hab' mich jetzt für Mercurial entschieden....

Nachdem ich bisher noch überhaupt nicht mit einer Versionskontrolle gearbeitet habe, hätte ich noch ein paar Verständnisfragen:

1. Mit 'hg branch' wird meine Arbeitskopie als Zweig markiert. Mit 'hg clone' erstelle ich einen Klon/eine Kopie des gesamten oder eines speziellen Repository. Ich verstehe den Unterschied nicht wirklich. Ohne jetzt eine haargenaue Anleitung zu benötigen, aber wie gehe ich denn vor, wenn ich vom aktuellen Stand aus einen Zweig eröffnen möchte?

Als zumindest Anfänger mit Mercurial ist es oft einfacher für jedes Repository einen neuen Klon zu machen. Der Platzbedarf dafür ist minim da Hardlinks verwendet werden. Wir haben hier mehr als 100 Klone von einem 80'000 Revisions/2GB repository auf einer VM. Klonen dauert auch nur wenige Sekunden unter Linux. Auf Windows 2-3 Minuten. Bei einem kleineren Repository dürfte es aber immer mehr oder weniger sofort gehen.

2. Ich habe gerold's Vorschlag übernommen und mir Trac installiert. Um Programmfeatures zu definieren und diese dann Versionen und Komponenten zuzuordnen ist das eine prima Sache. Auch kann ich mir vorstellen, künftig nicht mehr so schnell den Faden zu verlieren, wenn man mal etwas länger nicht mehr bei der Sache war... Für Trac gibt es ja auch eine Mercurial-Unterstützung. Wie kann ich mir das konkret vorstellen, wenn ich z. B. ein Ticket abarbeite: An welcher Stelle kommt hier Mercurial ins Spiel? Wenn ich das Ticket erledigt habe, d. h. neue Programmfeatures fertiggestellt sind, dann mache ich in Mercurial einen commit und in Trac wird das Ticket als erledigt gekennzeichnet. Weshalb muss da eine Verbindung zwischen Trac und Mercurial bestehen?

Müssen? Gar nicht. Aber um ehrlich zu sein würde ich dir Bitbucket empfehlen. Da hast du alles bereits schön integriert und musst dir auch um Backups keine Sorgen machen.

3. Ähnlich mit der VIM-Unterstützung: Welchen Vorteil hat eine solche Verzahnung zwischen Editor und Mercurial?

Soll wohl Zeit sparen. Ich verwende aber nichts in diese Richtung.

Ein Mercurial Feature das ich dir nahe legen kann ist MQ. Schau es dir einfach einmal an.

http://hginit.com/ noch zur Hilfe.

Gruss,
Jonas

Gruss,
Jonas

[Pekh]

Ok, prinzipiell klar, nur, muss nicht jeder Zweig, um testbar zu bleiben, den kompletten Inhalt eines Programmes beinhalten? Zudem 'hg clone' ja auch die komplette Version eines Repository's kopiert. Konkret: Wenn ich ein Arbeitsverzeichnis mit 'a.py', 'b.py' und 'c.py' habe und darauf basierend einen Zweig mit 'hg clone' eröffne, erhalte ich wieder ein Arbeitsverzeichnis mit den 3 Dateien. Um in Deinem Bereich zu bleiben: Wenn Du für 5 Kunden 5 variierende Programme pflegst, dann beinhalten die 5 Zweige doch immer auch alle Dateien des Hauptprogrammes, selbst wenn Du bei einem Kunden z. B. nur Änderungen an 'b.py' vornimmst. Oder steh' ich jetzt total auf der Leitung...?

Nein, das ist schon richtig. Nur daß es halt nicht mehr für jeden Zweig dutzende Sicherungskopien gibt, sondern nur noch die eine Arbeitskopie. Ich denke, du versteifst dich da zu sehr auf das Sparen von Speicherplatz. Das ist definitiv nicht der Hauptvorteil der Versionsverwaltung. Stattdessen hast du die Möglichkeit, auch zu kleinsten Zwischenschritten zurückkehren zu können, ohne lange suchen zu müssen. Oder halt auch Änderungen über einen gewissen Zeitraum verfolgen zu können (-> diff). Oder Änderungen zwischen Zweigen teilen zu können. Und nicht zu vergessen: Wenn du verschiedene Zweige wieder zusammenführen willst, nimmt dir Mercurial den größten Teil der Arbeit ab, in dem es dich nur an Stellen fragt, wo wirklich ein Konflikt besteht und den Rest automatisch erledigt.

[ms4py]

3. Ähnlich mit der VIM-Unterstützung: Welchen Vorteil hat eine solche Verzahnung zwischen Editor und Mercurial?

Falls du nicht zwangsläufig VIM verwendest: Die Mercurial-Integration in Netbeans ist wirklich top!

[mutetella]

Nur daß es halt nicht mehr für jeden Zweig dutzende Sicherungskopien gibt, sondern nur noch die eine Arbeitskopie. Ich denke, du versteifst dich da zu sehr auf das Sparen von Speicherplatz.

Da hast Du Recht. Ich hänge immer noch in der Vorstellung fest, dass es ein Arbeitsverzeichnis gibt, von dem aus ich alles erreiche:
- Das Hauptprogramm
- Neue Features in der Testphase
- Bugs, die gerade behoben werden
- etc.
Nur um nochmal sicher zu gehen: Es ist also nicht am Ziel vorbei, wenn ich für diese Dinge jeweils ein neues Verzeichnis (neues Repo/neuen Zweig) anlege?

Falls du nicht zwangsläufig VIM verwendest

Doch, ich verwende "zwangsläufig" VIM. Bin ungefähr 1 Jahr immer um VIM herumgekreist, fand' diesen Editor immer irgendwie reizvoll, aber einfach saublöd zu bedienen. Inzwischen weiß ich, dass der Reiz gerade in der "saublöden" Bedienung liegt. Hab' mich vor ein paar Wochen nun voll auf VIM eingelassen und liebe dieses Teil wie kein anderes Tool!!! Sobald ich einen Text mit OO oder gedit oder sonstwas schreibe, sind da plötzlich lauter 'i'-s oder 'jjjj'-Folgen drin...

Aber um ehrlich zu sein würde ich dir Bitbucket empfehlen.

Scheint wirklich 'ne runde Sache zu sein, aber was ich jetzt beim Überfliegen so gesehen hab', ist nur 1 Repo kostenfrei und das ganze für mein (noch) kleines Ein-Mann-Projekt doch ein wenig zu taff... Aber danke für den Tipp, ich behalt' das im Hinterkopf!

Ein Mercurial Feature das ich dir nahe legen kann ist MQ. Schau es dir einfach einmal an.

Danke, werd' ich machen...

Gruß
mutetella


P.S.: Warum springt der interne Editor eigentlich bei jedem Klick auf 'Quote', 'Python' oder so immer auf den Textanfang? Ist echt nervig!

[.robert]

Scheint wirklich 'ne runde Sache zu sein, aber was ich jetzt beim Überfliegen so gesehen hab', ist nur 1 Repo kostenfrei und das ganze für mein (noch) kleines Ein-Mann-Projekt doch ein wenig zu taff... Aber danke für den Tipp, ich behalt' das im Hinterkopf!

Nein, du hast unbegrenzte Repos, aber nur ein Privates Repo, bei der Kostenfreien Version.
Siehe auch: http://bitbucket.org/plans

Nachtrag:
Bei github ht man übrigens bei der kostenfreien Version gar kein Privates und nur öffentliche Repos
http://github.com/plans

Ausßerdem hat man bei bitbucket 1GB speicher, bei github nur 300mb

[Pekh]

Nur daß es halt nicht mehr für jeden Zweig dutzende Sicherungskopien gibt, sondern nur noch die eine Arbeitskopie. Ich denke, du versteifst dich da zu sehr auf das Sparen von Speicherplatz.

Da hast Du Recht. Ich hänge immer noch in der Vorstellung fest, dass es ein Arbeitsverzeichnis gibt, von dem aus ich alles erreiche:
- Das Hauptprogramm
- Neue Features in der Testphase
- Bugs, die gerade behoben werden
- etc.
Nur um nochmal sicher zu gehen: Es ist also nicht am Ziel vorbei, wenn ich für diese Dinge jeweils ein neues Verzeichnis (neues Repo/neuen Zweig) anlege?

Ja, genauso ist es vorgesehen. Noch mal zur Verdeutlichung: Angenommen ich habe ein Projekt, von dem bereits eine Version beim Kunden zwecks testen oder gar schon im Produktiveinsatz ist. Inzwischen läuft die Entwicklung weiter. Ich habe also ein Haupt-Repo (auf das auch Trac zeigt), sowie eine Arbeitskopie, in der ich gerade rumpfusche. Jetzt kommt mitten drin der Kunde und meldet einen Fehler. Ich lege die Entwicklungskopie also erst mal beiseite und checke aus dem Hauptrepo die Version aus, die auch der Kunde hat, und versuche, den Fehler zu finden und zu beheben. Letztlich habe ich jetzt also zwei Arbeitskopien. Das hat folgenden Grund: Zum einen ist die Entwicklungsversion im Hauptrepo meistens schon fortgeschrittener als die Version, die der Kunde hat. Eventuell tritt der Fehler in der aktuellen Version auch gar nicht mehr auf (-> Unittest in der "Fehlerkopie" entwickeln und in die "Entwicklungskopie" übernehmen, dann schauen ob er dort auch fehlschlägt ... ). Zum anderen vermischt man sich die Änderungen, wenn man alles zwanghaft in der selben Kopie machen will. Grundregel: Jede Änderung ein Commit. Nicht-zusammenhängende Änderungen sollten niemals im selben Changeset landen.

Wenn ich mit dem Beheben des Fehlers fertig bin, schiebe ich ihn ins Haupt-Repo (und liefere ggf. einen Patch aus). Dann schwinge ich mich wieder an die Entwicklungskopie und bringe die Änderungen dort zu ende. Anschließend ziehe ich mir alle Änderungen, die sich inzwischen im Hauptrepo angesammelt haben, in die Entwicklungskopie und bringe alles zusammen zum Funktionieren ("branch merge"). Anschließend werden die zusammengeführten Änderungen wieder ins Hauptrepo zurückgeschoben.

Ich habe für mich selbst die Maxime gesetzt, daß sich im Hauptrepo zu jedem Zeitpunkt immer nur eine "lauffähige" Version befindet. Was auch immer das angesichts des aktuellen Entwicklungsstandes bedeuten mag. Das kann man so machen, muß man aber nicht. Aber es erklärt den obigen Arbeitsablauf hoffentlich ein bisschen.

[mutetella]

@Pekh:
Vielen Dank für die Hilfe. Das hat jetzt ein paar Knoten in meinem Hirn gelöst...


Und danke an alle anderen...

Gruß
mutetella

[jens]

Noch mal was zu git + eclipse...

Dem EGit plugin fehlen leider noch essenzielle Ding z.Z. git pull und merge...

Kennt jemand sonst noch gute GUI's zu git und kann eins empfehlen? (unabhängig von Eclipse)

[ms4py]

Noch mal was zu git + eclipse...

Dem EGit plugin fehlen leider noch essenzielle Ding z.Z. git pull und merge...

Kennt jemand sonst noch gute GUI's zu git und kann eins empfehlen? (unabhängig von Eclipse)

Die jeweilige Version von Tortoise für jedes VCS zu gebrauchen (nur Windows).

[jens]

suche ehr was für linux

[Leonidas]

Die jeweilige Version von Tortoise für jedes VCS zu gebrauchen (nur Windows).

TortoiseHg geht auch unter Linux. Aber ich nutze generell keine GUIs mehr für DVCS. Höchstens mal so Visualisierungskram wie ``hgtk`` oder ``giggle``.

[lunar]

qgit4

[mutetella]

Aber ich nutze generell keine GUIs mehr für DVCS.

Hat das einen "tieferen" Grund? Oder tendierst Du generell eher zur Konsole als zur Maus?

Gruß
mutetella

[Leonidas]

Hat das einen "tieferen" Grund? Oder tendierst Du generell eher zur Konsole als zur Maus?

Das sowieso, aber ich habe auch das Gefühl dass das geklicke viel ineffizineter ist als wenn ich direkt in der Konsole, wo ich auch programmiere, schnell mal ``hg commit -m 'Nachricht'`` schreibe, als wie wenn ich nen Dateimanager auftreiben muss, den Ordner raussuchen muss und dort dann rumklicke.

Zudem arbeite ich oft über SSH, da habe ich dann sowieso kein X11, daher hat es sich dann auch von der Hinsicht erledigt.

[.robert]

Moin moin,

würdet ihr eigentlich Trac als Webbasierte SCM und Project Management Tool im Zusammenspiel mit Mercurial empfehlen, oder gibt es da (im Hinblick auf hg) Lösungen, die eher zu empfehlen wären?

Und ich meine jetzt nicht bitbucket, es geht schon um eine private und selbst gehostete Lösung

Was setzt ihr ein?

Gruß,
r.