Welches SCM benutzt ihr?

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)

DEvent

Dravere schrieb:

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.

Das glaube ich dir aber jetzt nicht. http://git-scm.org/course/svn.html
Fast alle Befehle sind identisch und die git Befehle sind konsistenter. Z.B. tag

git tag -a name  	svn copy http://example.com/svn/trunk http://example.com/svn/tags/name

Oder branchen:

git branch branch
git checkout branch 	svn copy http://example.com/svn/trunk http://example.com/svn/branches/branch
                        svn switch http://example.com/svn/branches/branch

Oder gar mergen

git merge branch  	(assuming the branch was created in revision 20 and you are inside a working copy of trunk)
svn merge -r 20:HEAD http://example.com/svn/branches/branch

drakon schrieb:

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..

Ist alles sehr einfach. Mit git-grep, git-log, git-show. Alle Parameter, die ein "tree" Objekt erwarten kannst du entweder mit dem (partiallen) Sha-Hash, mit HEAD oder mit ^^^HEAD ansteuern.

Z.B. git log

commit 6566cee3f9ecedd545aeb59f646880b9cf3ba616
Author: Erwin Mueller <erwin.mueller@deventm.org>
Date:   Sun Dec 13 18:36:50 2009 +1100

    Fix pom.xml

git show 6566c

commit 6566cee3f9ecedd545aeb59f646880b9cf3ba616
Author: Erwin Mueller <erwin.mueller@deventm.org>
Date:   Sun Dec 13 18:36:50 2009 +1100

    Fix pom.xml

diff --git a/gs-calculator2-aboutdialog/pom.xml b/gs-calculator2-aboutdialog/pom.xm
index db5515e..6526b43 100644
--- a/gs-calculator2-aboutdialog/pom.xml
+++ b/gs-calculator2-aboutdialog/pom.xml
@@ -1,124 +1,110 @@
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/20
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/mav
- <modelVersion>4.0.0</modelVersion>
- <groupId>com.deventm.gscalc</groupId>
- <artifactId>gs-calculator2-aboutdialog</artifactId>
- <version>0.0.1-SNAPSHOT</version>
+    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/
+    <modelVersion>4.0.0</modelVersion>

Aber in einer GUI ist das natürlich viel bequemer.

drakon

Ich denke Dravere meinte vor allem das arbeiten mit der GUI.

Ich kann dir sagen, wie ich SVN "gelernt" habe. Ich habe mir TortoiseSVN runtergeladen, mir das allgemeine Tutorial zu Versionierung angeschaut (kannte ich vorher gar nicht) und dann habe ich da ein wenig mit der GUI rumgespielt und das hat alles gut funktioniert. Und das ohne einen einzigen SVN Befehl kennen zu müssen, geschweigen denn Parameter usw. in einer Doku nachschlagen müssen.

Wie gesagt ich wüsste bis jetzt nicht, wie ich etwas ausserhalb von TortoiseSVN machen könnte. Also Befehle direkt absetzen.. Braucht man in den meisten Fällen ja auch nicht.

Aber in einer GUI ist das natürlich viel bequemer

Ok. Das wollte ich eigentlich hören.
Aber du benutzt dafür trotzdem keine GUI?

rüdiger

Dravere schrieb:

@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.

Nein, VIM ist nicht der Standardeditor von GIT! Nur bei der Distribution, die du runtergeladen hast. msysgit packt eben noch alle möglichen anderen Sachen dazu. VIM gehört aber nicht zu GIT und ist nicht der Standardeditor von GIT. GIT hat keinen Standardeditor und öffnet einfach den Standardeditor den man einstellt.

Schau dir vielleicht mal TortoiseGIT an. (Wobei ich nicht weiß, ob die nicht auch vim dazu packen. Aber ich hoffe mal nicht)

Dravere schrieb:

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.

Das nehme ich an. Aber wie gesagt: Probier mal eine andere "GIT für Windows"-Distribution.

@drakon
Dann nimm doch eine GUI für GIT. TortoiseGIT oder ein Plugin für die IDE deiner Wahl. SVN ist auch eine Konsolengeschichte und TortoiseSVN und die Plugins sind nur GUIs dafür. Genauso wie bei GIT.

EXDW

Also drakons Comment kann ich derzeit nicht verstehen.
Ich arbeite bisher mit TortoiseSVN und habe mir zum testen TortoiseGit installiert.
Die ähnlichkeit ist erstaunlich, funktioniert vieles in der handhabe identisch, sogar die Tools sind gleich.
Brauchte die Konsole bisher nur zum löschen von Tags und Branches.

Tipp: Shift gedrückt halten und dann rechtsklick, dann hat man mehr auswahl, und aus den Settings kann man noch mehr ein aus schalten.

drakon

Ich meinte halt die Angehensweise an Git ist anderst.
Wenn ich einfach mal git bei google eingebe, dann komme ich natürlich auf die Hauptseite und da weiter kommt man nicht zu einer Gui Installation, sondern zur Konsolenversion und die ersten Schritte passieren in der Konsole.
Bei SVN ist (zumindest bei mir) das anderst anbgelaufen. Ich kam irgendwie automatisch zu TortoiseSVN und auch gleich damit angefangen.

Die Herangehensweise ist halt für jemanden, der sich Gui gewohnt ist anderst und am anfang wahrscheinlich ein wenig verwirrender.

Klar benutze ich jetzt auch TortoiseGit, weil es halt ein paar Sachen einfacher macht.

@CSL
Was meinst du mit dem Shift? Ich habe keinen Unterschied festgestellt. Habe immer gleich viele Optionen..

rüdiger

Wenn ich svn bei Google eingebe, dann komm ich direkt zur alten SVN Seite (nicht TortoiseSVN) und auch auf der neuen SVN Seite erklärt die Doku den normalen SVN (=> Konsolenclient) und keine GUI.

Dravere

DEvent schrieb:

Das glaube ich dir aber jetzt nicht. http://git-scm.org/course/svn.html
Fast alle Befehle sind identisch und die git Befehle sind konsistenter.

Ich habe bisher keinen einzigen Befehl in SVN gekannt. Wozu auch? Erst jetzt durch die GIT Tutorials habe ich gelernt, dass es auch Befehle für SVN gibt

Ich habe SVN auch gleich mit TortoiseSVN kennen gelernt. Ganz ursprünglich dachte ich auch, dass es kein SVN ohne Tortoise gibt, bzw. dass SVN von den Tortoise Leuten entwickelt wurde
Jedenfalls habe ich nie die SVN Befehle gelernt, immer nur TortoiseSVN verwendet und die paar Klicks zu lernen und was sie auslösen, ist wirklich keine Hexerei. Auch kann man vieles sehr einfach auf die Verzeichnisse abbilden. Eine Revision als einfache Zahl welche inkrementiert wird, ist deutlich verständlicher. Ein Tag und zack hat man eine neue Verzeichnisstruktur. Der Trunk ist da, der Branch dort usw. usf.
Bei GIT ist alles versteckt. Was natürlich durchaus Vorteile hat, aber nicht gerade für das Verständnis förderlich ist. Auch die SHA1 Revisions sind sehr verwirrend, da man sie zu nichts in Bezug setzen kann. Und wenn man dann noch das Tutorial von GIT macht und bei einem git commit plötzlich ein VIM startet und im Tutorial nur steht, dass man den Kommentar eingeben soll und dann sei alles palletti, aber man gar keine Ahnung hat, wie man VIM bedienen soll ... ehm, ja
Auch das ganze mit dem Stage habe ich noch nicht ganz begriffen. Manchmal muss man commit machen, manchmal commit adment.

Ich denke mal es sind zwei Dinge:
1. Die Integration in Windows ist so la la.
2. GIT kann mehr als SVN, wodurch es automatisch auch mehr zu lernen gibt.

@rüdiger,
Und was öffnet GIT auf Windows, wenn man keinen Standardeditor angibt und kein VIM installiert wurde? Und wie gibt man zum Beispiel Notepad++ an? Der will das irgendwie nicht fressen.

Naja, wie gesagt, morgen nochmals anschauen.

Grüssli