Welches SCM benutzt ihr?

DEvent

rüdiger schrieb:

(autoload 'magit-status "magit" "git status" t)
(define-key global-map "\C-cm" 'magit-status)

Wenn du mir noch sagst, was ich damit machen soll

drakon

rüdiger schrieb:

drakon schrieb:

Das ist bestimmt nicht Vim. - Aber wahrscheinlich ist das von dem Programm her der Standardedtior, ja.

Ne, wenn du git nicht explizit sagst etwas anderes zu benutzen, dann nimmt er den Standardeditor und ich gehe mal davon aus, dass du nicht explizit auf vim gestellt hast :). Vermutlich hast du den Standardeditor nicht umgestellt. (zB export EDITOR=<editordeinerwahl> in .bashrc hinzufügen)

http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_environment_and_configuration_variables

Ehm. Ich habe Windows XP und ich bezweifle, dass Vim da vorinstalliert ist, geschweige denn, dass ich den als Standareditor eingstellt habe. Vor allem, da ich den Heute das erste mal gesehen habe.

@DEvent
Rein Befehle eintippen geht wahrscheinlich je nach dem schon schneller, aber wie siehts aus mit History anschauen? Oder mit Diffs auflösen? Das wirst du ja alles nicht in der Konsole machen..
Oder aber auch Files auswählen, welche commitet werden. Ich würde da nicht jedes einzelne File dadurch auswählen wollen, indem ich den Namen eintipppen muss..

Mr. N

drakon schrieb:

Ehm. Ich habe Windows XP und ich bezweifle, dass Vim da vorinstalliert ist, geschweige denn, dass ich den als Standareditor eingstellt habe. Vor allem, da ich den Heute das erste mal gesehen habe.

VIM kommt mit dem Mingw Git. Du kannst den Editor aber auch ändern (siehe Doku), oder mit -m eine Nachricht übergeben. Beispiel:

git commit -a -m "This commit has a very nice commit message"

Oder du verwendest ein GUI-Tool. Aber da kann ich nix empfehlen, weil das nicht meine Sache ist.

rüdiger

DEvent schrieb:

rüdiger schrieb:

(autoload 'magit-status "magit" "git status" t)
(define-key global-map "\C-cm" 'magit-status)

Wenn du mir noch sagst, was ich damit machen soll

In die ~/.emacs schreiben. Vielleicht noch vorher mit (add-to-list 'load-path "PFAD") den Pfad zum load-path hinzufügen, wo du magit.el(c) installiert hast.

drakon schrieb:

rüdiger schrieb:

drakon schrieb:

Das ist bestimmt nicht Vim. - Aber wahrscheinlich ist das von dem Programm her der Standardedtior, ja.

Ne, wenn du git nicht explizit sagst etwas anderes zu benutzen, dann nimmt er den Standardeditor und ich gehe mal davon aus, dass du nicht explizit auf vim gestellt hast :). Vermutlich hast du den Standardeditor nicht umgestellt. (zB export EDITOR=<editordeinerwahl> in .bashrc hinzufügen)

http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_environment_and_configuration_variables

Ehm. Ich habe Windows XP und ich bezweifle, dass Vim da vorinstalliert ist, geschweige denn, dass ich den als Standareditor eingstellt habe. Vor allem, da ich den Heute das erste mal gesehen habe.

Komisch, dann hast du irgend ein Git-Windows-Paket gezogen, wo wohl jemand Vim dazu gepackt hat. Hätte nicht gedacht, dass das jemand so etwas macht. Aber das hängt eben mit den Leuten zusammen, die das Paket gemacht haben und nicht mit git direkt.

drakon

Mr. N schrieb:

drakon schrieb:

Ehm. Ich habe Windows XP und ich bezweifle, dass Vim da vorinstalliert ist, geschweige denn, dass ich den als Standareditor eingstellt habe. Vor allem, da ich den Heute das erste mal gesehen habe.

VIM kommt mit dem Mingw Git. Du kannst den Editor aber auch ändern (siehe Doku), oder mit -m eine Nachricht übergeben. Beispiel:
git commit -a -m "This commit has a very nice commit message"
Oder du verwendest ein GUI-Tool. Aber da kann ich nix empfehlen, weil das nicht meine Sache ist.

Klar kann ich was anderes nehmen. Werde ich auch, aber ich wollte da halt nur sagen, dass ich sowas einfach schreklich zu benutzen finde. Ich will nicht erst ein Manual lesen müssen, bevor ich einen Textedtior benutze..

@rüdiger
Scheint so, ja. Ich habs von da:
http://code.google.com/p/msysgit/

DEvent

drakon schrieb:

Rein Befehle eintippen geht wahrscheinlich je nach dem schon schneller, aber wie siehts aus mit History anschauen? Oder mit Diffs auflösen? Das wirst du ja alles nicht in der Konsole machen..
Oder aber auch Files auswählen, welche commitet werden. Ich würde da nicht jedes einzelne File dadurch auswählen wollen, indem ich den Namen eintipppen muss..

git mergetool öffnet dir ein Merge-Tool für jeden merge-Konflikt. git diff und git log ist in der Konsole auch ganz gut. git log --graph zeigt dir auch ein Graph der Branches und Logs an.

Mit git config --global color.ui true hast du auch Farbe.

drakon

Hmm. Ich würde mal gern sehen, die du damit arbeitest.
(das mein ich jetzt ernst, weil ich kanns mir iwie nicht richtig vorstellen, weil das halt mit GUI so viel einfacher ist..)

z.B Das mit dem Graph. In der Konsole gibt es ja anscheinend eine Navigation mit der Tastatur. Wie genau das funktioniert weiss ich jetzt nicht. Müsste also im Manual naschauen. In der GUI ist das sofot klar, wie das geht.

DEvent

drakon schrieb:

Hmm. Ich würde mal gern sehen, die du damit arbeitest.
(das mein ich jetzt ernst, weil ich kanns mir iwie nicht richtig vorstellen, weil das halt mit GUI so viel einfacher ist..)

z.B Das mit dem Graph. In der Konsole gibt es ja anscheinend eine Navigation mit der Tastatur. Wie genau das funktioniert weiss ich jetzt nicht. Müsste also im Manual naschauen. In der GUI ist das sofot klar, wie das geht.

Was gibt es da groß zu arbeiten? 7 Befehle, die ich benutze, den Rest der Zeit programmiere ich. Vielleicht liegt es an Git, aber mehr als add, commit und push mache ich nicht (und checkout/merge je nach Lust und Laune).

byto

rüdiger schrieb:

byto schrieb:

Mich würd mal interessieren, ob hier jemand zusätzlich zu VCS einen Continous Integration Server benutzt?

Was soll ein Continous Integration Server sein?

Bei Continous Integration gehts im im Grunde darum, die Sourcen automatisisch zu testen und zu zu builden. Hier die Definition von Fowler:

http://martinfowler.com/articles/continuousIntegration.html

* Maintain a Single Source Repository.
* Automate the Build
* Make Your Build Self-Testing
* Everyone Commits To the Mainline Every Day
* Every Commit Should Build the Mainline on an Integration Machine
* Keep the Build Fast
* Test in a Clone of the Production Environment
* Make it Easy for Anyone to Get the Latest Executable
* Everyone can see what's happening
* Automate Deployment

TeamCity ist ein freier Continous Integration Server mit einem Haufen von Funktionen. Einfach mal hier reingucken:

http://www.jetbrains.com/teamcity/features

EXDW

drakon schrieb:

@rest:
Niemand benutzt TortoiseGit? - Falls doch gleich mal ne Frage dazu: Wie entfernt man denn da wieder einen erstellten Branch? Habe bis jetzt leider keine Möglichkeit mit TortoiseGit gefunden..

Also ich Teste derzeit ja Git, und das mit TortoiseGit damit zum anfang hin die umgewöhnung nicht so schwer fällt.
Auf jeden fall habe ich gemerkt das man Branches und Tags nicht per Tortoise löschen kann, da musste ich die Console benutzen, war aber einfacher als gedacht

Rechtsklick im Repository -> "Git Bash Here" (Einfaches CMD mit navigation zum respository geht auch)
und dann

Tags löschen:
git tag -d MyTagName

Branches löschen:
git branch -d MyBranchName

Bisher Positiv aufgefallen:
- Das Respository ist auch gleich der Arbeits Ordner, das vereinfacht das Backup.
- Das nicht überall ein info Ordner erstellt wird (.git oder .svn) bei Git gibts das nur im Root.

Bisher Negativ aufgefallen:
- Man kann sich nicht den Branch Tree einer Datei oder Verzeichnisses an schauen, man muss sich mit der Log begnügen, finde das sehr unübersichtlich
- Wenn man lokal in einem Branch etwas geändert hat und das noch nicht submitten will, kann man kein anderen Branch in einem anderen Verzeichnis auschecken, also zwei Branches gleichzeitig auf der Festplatte. Ich kann bisher immer nur mit Switch wechseln.

Was mir am Anfang passiert war.
Ich erstellte ein Repository in einem Ordner, kopierte ein Projekt rein und submittete das in den master als initial version.
Dann habe ich das nach einem dev abgebrancht (ohne zu switchen).
Dann kopierte ich ein weiteres Projekt daneben (Im selben repository) und wollte das auch abbranchen, dann hieß es das dieser Branch schon existierte, wunderte mich und wollte das Projekt dann nach dev Switchen.
Dann war mir alles eingefrohren, nachdem nach kurzer zeit (~2 min) wieder alles lief konnte ich in den Projekt ordner nicht mehr rein, konnte den nicht wieder zurück wechseln, und löschen auch nicht.

Ich habe es am ende beim neu aufziehen so gemacht das ich alle 3 Projekte gleichzeitig in master committed und abgebrancht habe, wie man richtig neue Projekte hinzu fügt weiß ich nicht, nach master wechseln, rein kopieren und dann in master submitten kann ich mir noch vorstellen, aber wie ich diese sourcen dann nach dev abbranche ist mir ein raetsel...

//Dazu
Was mir dazu noch einfällt.
Währe es bei Git eventuell besser ein Repository pro Projekt zu haben? Ich habe bisher ein Repository für 3 Projekte.

Christoph

CSL schrieb:

Wenn man lokal in einem Branch etwas geändert hat und das noch nicht submitten will, kann man kein anderen Branch in einem anderen Verzeichnis auschecken, also zwei Branches gleichzeitig auf der Festplatte. Ich kann bisher immer nur mit Switch wechseln.

git stash könnte das sein, was du suchst.

Alternativ kannst du auch committen. Der Commit bleibt ja lokal bei dir, davon sieht niemand etwas. Später kannst du dann mit "git commit --amend" den commit ändern oder mit git reset den commit ganz entfernen und neu erstellen. Ein Beispiel, wie das geht, steht in der man-page von git-reset.

Mr. N

CSL schrieb:

Währe es bei Git eventuell besser ein Repository pro Projekt zu haben? Ich habe bisher ein Repository für 3 Projekte.

Ja, ein Projekt pro Repository ist sinnvoll. Du kannst aber auch ein Master-Projekt bauen, das die Unterprojekte dann z.B. per Submodules anzieht.

abc.w

DEvent schrieb:

drakon schrieb:

Hmm. Ich würde mal gern sehen, die du damit arbeitest.
(das mein ich jetzt ernst, weil ich kanns mir iwie nicht richtig vorstellen, weil das halt mit GUI so viel einfacher ist..)

z.B Das mit dem Graph. In der Konsole gibt es ja anscheinend eine Navigation mit der Tastatur. Wie genau das funktioniert weiss ich jetzt nicht. Müsste also im Manual naschauen. In der GUI ist das sofot klar, wie das geht.

Was gibt es da groß zu arbeiten? 7 Befehle, die ich benutze, den Rest der Zeit programmiere ich. Vielleicht liegt es an Git, aber mehr als add, commit und push mache ich nicht (und checkout/merge je nach Lust und Laune).

Nun, das mit git muss ich mir auch anschauen... stelle es mir aber im Moment zu kompiliziert vor. Vielleicht bin ich mit der GUI (Eclipse) und CVS zu verwöhnt und kenne es ja auch nicht anders.

rüdiger

@abc.w
Für git muss man nicht die Konsole benutzen. Es gibt ja einige GUIs, zB für Eclipse http://www.eclipse.org/egit/ Aber kA wie gut das ist. Benutze kein Eclipse.

Ich denke bei git nutzen aber viele Leute gerne die Konsolenvariante, da die meisten GUIs einfach nicht alle Features von git anbieten (bei der Featureanzahl ist es sicher auch aufwendig jedes Detail zu implementieren). Aber wenn man git nur wie SVN/CVS benutzt, dann dürften die GUIs vollkommen ausreichen (also commit -a/push/pull/log/diff und noch ein paar Sachen).

Ich mach den größten Teil auch via magit.

drakon

DEvent schrieb:

drakon schrieb:

Hmm. Ich würde mal gern sehen, die du damit arbeitest.
(das mein ich jetzt ernst, weil ich kanns mir iwie nicht richtig vorstellen, weil das halt mit GUI so viel einfacher ist..)

z.B Das mit dem Graph. In der Konsole gibt es ja anscheinend eine Navigation mit der Tastatur. Wie genau das funktioniert weiss ich jetzt nicht. Müsste also im Manual naschauen. In der GUI ist das sofot klar, wie das geht.

Was gibt es da groß zu arbeiten? 7 Befehle, die ich benutze, den Rest der Zeit programmiere ich. Vielleicht liegt es an Git, aber mehr als add, commit und push mache ich nicht (und checkout/merge je nach Lust und Laune).

Ja, den grössten Teil der Zeit schon, aber sagen wir du möchtest mal schauen, was ein File so für eine Version zu einem bestimmten Zeitpunkt hatte. Das mit dem Graphen in der Konsole zu machen ist denke recht mühsam. Und wie die richtige Version dann ansteuerst weiss ich in der Konsole z.B auch nicht..

@CSL
Jup. Das kenn ich schon auch, aber dachte halt, da branchen ja zu einer der Punkte gehört, die in Git sehr gut gelöst ist, dass es da auch eine ausführlichere Gui gibt, als für andere Teile. Über die bash ist es natürlich kein Problem.

EXDW

Nun habe ich hier was merkwürdiges in Git.

Ich hatte in einem Projekt etwas editiert, und die änderung dann manuell rück gängig gemacht.
Sodass die Datei wieder in ursprung zurück ist.

Nun ist der Ordner bis runter zur Datei als "geändert" markiert (Das Icon).

-> Check for Modifications: Keine
-> Revert: Nichts zur Auswahl

Erst ein erneuter Checkout aktualisierte es entsprechend.
Fand das sehr merkwürdig, und macht auch ein ungutes gefühl das man sich denkt da währe etwas unsubmittiertes.

drakon

Da hilft manchmal ein Reload auf des Explorers.

EXDW

Schon Probiert Hatte sogar den TC und den Explorer komplett neu gestartet.

Dravere

@rüdiger, drakon & Mr.N,
(Ich hoffe mal, dass ich mich an die richtigen Namen erinnert habe)
Zum Thema VIM:
Der Standardeditor bei GIT ist VIM. Und zwar VIM in der Konsole. Ich bin auch völlig erschrocken, als nach dem git commit plötzlich dieses seltsame Ding geöffnet hat, welches ich partout nicht mehr geschlossen bekommen habe. Und als ich dann auf das X gedrückt habe, ist der ganze Commit abgebrochen.

Als ich dann in den Settings mein Notepad++ eintragen wollte, ging das gar nicht. Kein gültiger Editor oder sowas. Hätte mich auch überrascht, wie sollte dies schliesslich gehen?

Bisheriger Eindruck von GIT: Kompliziert
SVN kann man innert 30 Minuten ziemlich weitgehend lernen oder zumindest einen Überblick bekommen. Bei GIT ist mir das irgendwie noch nicht gelungen, ich habe noch nicht einmal eine annähernde Übersicht. Aber so langsam kommt es.

Der Verlgeich zwischen GIT und x fand ich ganz interessant, aber bisher wegen der ganzen Komplexität von GIT noch nichts davon sehen können
Werde mich morgen nochmals, bzw. vielleicht einmal ein wenig länger, damit beschäftigen. Und dann vielleicht mal ein kleineres Projekt damit austesten. Derzeit bleibe ich noch bei SVN.

Kurz noch was zur Komplexität:
Die könnte durchaus auch daher kommen, dass GIT und Windows noch nicht so gut harmonisieren. Zum Beispiel funktioniert git diff mit GitExtension nicht, wodurch man wieder auf die Konsole wechselt und dann bei git commit sich wieder über GIT ärgert, weil dort dann dieses VIM kommt. Tools wo man hin und her wechseln muss, zwischen verschiedenen Oberflächen sind immer mühsam.

Grüssli

drakon

Da sehe ich auch noch den Hauptnachteil (und den einzigen) in Git. Die Integration. Ich als Windows User bin es mich einfach nicht gewohnt alles mit der Konsole zu machen und bevorzuge halt nun einfach mal ein Gui und möchte nicht für jedes kleine Detail ein Manual hervorziehen.

In dem Sinne ist nicht Git komplizierter, als andere SCM, sondern die Integration für Windows User ist nicht wirklich gut. Vor allem, wenn dann so Dinge, wie VIM aufgehen und man erstmal keine Ahung hat, was da abgeht.. ( kleiner Tipp für Dravere: ESC -> :q bringt dich wieder aus Vim raus. Mit :w kannst du speichern, am besten mal das über die Modi in Vim in der Doku nachlesen)

In dem Sinne liegt das Problem ja nicht direkt an Git, sondern an den mangelnden Leuten, die Tools dafür für Windows schreiben. - Aber eigentlich gehts mit TortoiseGit ja auch recht gut und reicht wohl für die üblichen Dinge.
(ich wüsste z.B nicht, wie ich bei SVN speziellere Dinge machen kann. Bei Git weiss ich, dass ich aus der Konsole alles rausholen kann)