Welches SCM benutzt ihr?

DEvent

drakon schrieb:

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?

Vielleicht um mir das Diff anzuschauen oder im Log zu blättern und KDiff um merge-conflict aufzulösen. Aber für add, commit, push geht Konsole viel schneller.

Zu SVN, ich habe damals mit Windows SVN durch Konsole kennen gelernt. Später habe ich dann TortoiseSVN installiert. Ich fand alles sehr schwierig, vor allem weil man nicht einfach so Dateien/Verzeichnisse löschen oder umbenennen kann und man ständig eine Verbindung zum SVN Server braucht. Dann wird jedes Verzeichnis mit dem .svn Unterverzeichnisse ge-spammt. Wer sich so ein Misst wohl ausgedacht hat.

drakon

DEvent schrieb:

drakon schrieb:

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?

Vielleicht um mir das Diff anzuschauen oder im Log zu blättern und KDiff um merge-conflict aufzulösen. Aber für add, commit, push geht Konsole viel schneller.

Eben. Dachte, dass sich diese Funktionen niemand freiwillig in der Konsole gibt.

hustbaer

_matze schrieb:

;fricky schrieb:

wenn man's nur mit fünf bis zehn kleinen programmen zu tun hat, an denen man alleine arbeitet, geht's natürlich auch ohne.

Wir arbeiten in der Firma aber natürlich mit mehreren an einer halbwegs großen Software (ca. 500.000 LOC waren es mal, mittlerweile dürften es mehr sein) und mehreren kleineren Tools.

Der Austausch per E-Mail funktioniert natürlich auch, klar. Aber allein schon Änderungen nachzuverfolgen ist ein Graus.

Das soll jetzt ein Scherz sein, oder?

Erhard Henkes

Gibt es einen objektiven Vergleich im Sinne von PROs & CONs bezüglich Subversion und Git?

DEvent schrieb:

Zu SVN, ich habe damals mit Windows SVN durch Konsole kennen gelernt.

kein wunder, dass du SVN dann doof findest. programme über konsolenbefehle zu bedienen ist doch immer nervig, egal welche, unter windows besonders.

DEvent schrieb:

Ich fand alles sehr schwierig ... und man ständig eine Verbindung zum SVN Server braucht.

brauchste nur zum commit, update usw. nicht ständig.

DEvent schrieb:

Dann wird jedes Verzeichnis mit dem .svn Unterverzeichnisse ge-spammt. Wer sich so ein Misst wohl ausgedacht hat.

wie machen das denn andere VCS? irgendwo müssen die ja auch infos unterbringen, dass irgendwas unter versionskontrolle ist.

EXDW

drakon schrieb:

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

Wenn du Shift gedrückt hälst, und dann rechtsklick auf die Datei, hast du mehr Optionen, ist auch bei TortoiseSvn so.

Ohne Shift:
http://downloads.my-libraries.de/Pictures/TortoiseGit_1.png
Mit gedrückten Shift:
http://downloads.my-libraries.de/Pictures/TortoiseGit_2.png

nman

;fricky schrieb:

DEvent schrieb:

Ich fand alles sehr schwierig ... und man ständig eine Verbindung zum SVN Server braucht.

brauchste nur zum commit, update usw. nicht ständig.

Serververbindung beim Commiten und Commit=Publishing ist schon ziemlich tödlich. Das führt zu ziemlich unangenehmem Commit-Verhalten.

Aber man braucht die Verbindung ja auch für diff und für bisect und log und viele andere Sachen, die man doch häufiger verwendet.

DEvent schrieb:

Dann wird jedes Verzeichnis mit dem .svn Unterverzeichnisse ge-spammt. Wer sich so ein Misst wohl ausgedacht hat.

wie machen das denn andere VCS? irgendwo müssen die ja auch infos unterbringen, dass irgendwas unter versionskontrolle ist.

Die meisten, die ich kenne, haben ein einzelnes Verzeichnis im Projekt-Root. Git hat zB. ein einziges .git/, Darcs hat ein einziges _darcs/, etc. Eben nicht pro Subdir.

DEvent

;fricky schrieb:

DEvent schrieb:

Zu SVN, ich habe damals mit Windows SVN durch Konsole kennen gelernt.

kein wunder, dass du SVN dann doof findest. programme über konsolenbefehle zu bedienen ist doch immer nervig, egal welche, unter windows besonders.

Nö, nur unter Windows. In Linux ist Konsole sehr bequem.

;fricky schrieb:

DEvent schrieb:

Ich fand alles sehr schwierig ... und man ständig eine Verbindung zum SVN Server braucht.

brauchste nur zum commit, update usw. nicht ständig.

Also ständig. Unter git commite ich jede Änderung und wechsle sehr oft zwischen den branches.

;fricky schrieb:

DEvent schrieb:

Dann wird jedes Verzeichnis mit dem .svn Unterverzeichnisse ge-spammt. Wer sich so ein Misst wohl ausgedacht hat.

wie machen das denn andere VCS? irgendwo müssen die ja auch infos unterbringen, dass irgendwas unter versionskontrolle ist.

Ein Verzeichnis reicht doch oder? Wie bei git, einfach ein .git Verzeichnis.

nman

Erhard Henkes schrieb:

Gibt es einen objektiven Vergleich im Sinne von PROs & CONs bezüglich Subversion und Git?

Bemüh doch mal die Forensuche, wir hatten zu dem Thema schon x Threads.

Und auch wenn Du es offensichtlich nicht für objektiv hältst, sieh Dir doch mal http://whygitisbetterthanx.com an und recherchiere ggf. selbst zu den angeführten Punkten.

Meine Lieblingsargumente:
- Git hat gutes Branching.
- Ein Commit bedeutet bei Git nicht, dass Du diese Änderungen auch sofort veröffentlichen musst, dh. Du kannst lokal committen wann und wieviel Du möchtest, ohne den anderen Devs irgendwas kaputt zu machen.
- Git funktioniert komplett Offline.
- Git benötigt keinen Server, funktioniert aber auch mit Server bestens.
- Git ist unheimlich schnell, Git-Repos sind unheimlich klein.

Beliebte Contras aus diesem Thread:
- Schlechte IDE-Integration, wenn Du nicht TortoiseGit oä verwenden möchtest.
- Für SVN-User anfangs etwas unintuitiv zu bedienen.

drakon

Erhard Henkes schrieb:

Gibt es einen objektiven Vergleich im Sinne von PROs & CONs bezüglich Subversion und Git?

Ich empfehle auch den Podcast des CCC's sehr gerne. Der geht nicht über Git, sondern stellt alles ein wenig vor und was halt Git anderst macht, als SVN und alle anderen. Und da kommt man dann selbst drauf, warum man eigentlich Git nehmen sollte und nix anderes.

@nman
Die Kontras sind imo nicht wirklich Nachteile direkt von Git gegenüber SVN. SVN ist genau so schwer zu benutzen, wie Git. Es ist ganz klar ein Grund, warum die Leute bei SVN bleiben, aber in dem Sinne finde ich das fast ein "unfairen" Grund, weil es kein technischer Nachteil von Git ist. Aber Das ganze wird sich denke ich noch arg verbessern.

Ein weiterer solchen "unfairen" Grund ist auch die Möglichkeit Projekte auf einem anderen Server zu hosten. Da wird es auch mehr Möglichkeiten für SVN geben, als für Git. Ist aber imo nur eine Frage der Zeit, bis sich das durchsetzt. (Auch im Businessbereich).

byto

SVN gibts halt schon länger als Git und ist deshalb weiter verbreitet. Ich habe mich persönlich auch noch nicht mit Git beschäftigt, weil ich bisher einfach noch weder die Zeit hatte noch die Notwendigkeit sah. Es ist doch im Grunde so, dass es viele alle möglichen Sachen in der Softwareentwicklung zig alternative Tools gibt. Es ist fast unmöglich geworden, für jedes Tool immer jede Alternative zu evaluieren, um die beste Lösung zu finden.

Ich habe jetzt schon viele gute Dinge über Git gelesen und finde es auch interessant. Irgendwann werde ich es mir mal angucken. Solange muss halt SVN weiter herhalten. SVN ist nicht perfekt, aber wenn man die Fallstricke kennt, kann man sie gut umschiffen.

Die Liste der zu evaluierenden Tools und APIs ist halt einfach zu groß und Git steht nicht oben auf dieser Liste. Dafür ist das Thema VCS einfach zu langweilig.

rüdiger

Dravere schrieb:

Auch die SHA1 Revisions sind sehr verwirrend, da man sie zu nichts in Bezug setzen kann.

Ja das stimmt. Das ist eben der Nachteil der verteilten Systeme. Wobei Mercurial afaik vorwärtszählende Versionsnummern hat.

Dravere schrieb:

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

Du willst mich wohl in den Wahnsinn treiben! Natürlich schreiben die nur, dass man seinen Kommentar eingeben soll. Die gehen davon aus, dass dein Standardeditor geöffnet wird. Also ein Editor mit dem du vertraut bist. VIM gehört nicht zu git und ist auch nicht der Standardeditor von git. Daher steht da auch keine Erklärung zu VIM. Das sich bei dir VIM geöffnet hat, liegt daran, dass du ein Paket von irgend jemandem gezogen hast, der halt git + vim + x in ein zip gepackt und eingerichtet hat.

Dravere schrieb:

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

Keine Ahnung. Ich habe bisher kein GIT unter Windows benutzt.

nman schrieb:

;fricky schrieb:

brauchste nur zum commit, update usw. nicht ständig.

Serververbindung beim Commiten und Commit=Publishing ist schon ziemlich tödlich.

was ist daran schlimm? meinste, wenn der server mal nicht ereichbar ist?

DEvent schrieb:

;fricky schrieb:

DEvent schrieb:

Zu SVN, ich habe damals mit Windows SVN durch Konsole kennen gelernt.

kein wunder, dass du SVN dann doof findest. programme über konsolenbefehle zu bedienen ist doch immer nervig, egal welche, unter windows besonders.

Nö, nur unter Windows. In Linux ist Konsole sehr bequem.

naja, konsolenbehle reinzuhacken ist grundsätzlich umständlicher als 'ne integration in eine IDE und für win-user ist sowas ungewohnter als für linuxer. ein gutes VCS lebt von benutzerfreundlichkeit und weniger von technischen feinheiten unter der haube.

DEvent schrieb:

;fricky schrieb:

DEvent schrieb:

Ich fand alles sehr schwierig ... und man ständig eine Verbindung zum SVN Server braucht.

brauchste nur zum commit, update usw. nicht ständig.

Also ständig. Unter git commite ich jede Änderung

was meinst du mit ständig 'ständig'? pro programmzeile ein 'commit'? *fg*

DEvent schrieb:

;fricky schrieb:

DEvent schrieb:

Dann wird jedes Verzeichnis mit dem .svn Unterverzeichnisse ge-spammt. Wer sich so ein Misst wohl ausgedacht hat.

wie machen das denn andere VCS? irgendwo müssen die ja auch infos unterbringen, dass irgendwas unter versionskontrolle ist.

Ein Verzeichnis reicht doch oder?

oder eine einzelne datei, das würde bestimt auch gehen. ich kann nicht einschätzen, was hiervon vorteilhafter ist.

nman

;fricky schrieb:

was ist daran schlimm? meinste, wenn der server mal nicht ereichbar ist?

Nein, das schlimmste ist, dass jeder Commit auch ein Publishing-Vorgang ist. Dh.:
- Ich darf nur committen, wenn ich mir sicher bin, dass ich für andere nichts kaputt mache, statt dann zu committen, wenn ich gerade einen Zustand erreicht habe, den ich irgendwie dokumentieren und festhalten möchte, bevor ich irgendwas anderes mache.
- Dadurch committe ich entweder sehr selten und arbeite dazwischen ohne Versionskontrolle oder mit manueller Versionskontrolle à la foo.c, foo.c.working, foo.c.working.old, … oder ich committe regelmäßig und störe andere Entwickler beim Arbeiten.
- Wenn ich im Flieger sitze oder irgendwo mitten in der Pampa, wo ich keinen Internetzugang habe, kann ich nicht committen, nicht updaten, nicht vernünftig Regressionen debuggen oä., weil ich keinen Zugriff auf alte Versionen habe.
- Jedesmal wenn ich an einem Feature arbeite und dabei irgendwo einen Bug finde, habe ich die Wahl, den gleich zu beheben und mit dem Feature-Commit zu vermischen, oder irgendwoanders das Repo auszuchecken, den Bug zu beheben und das zu committen, anstatt einfach bequem von der Feature-Branch wegzuwechseln oä.

naja, konsolenbehle reinzuhacken ist grundsätzlich umständlicher als 'ne integration in eine IDE und für win-user ist sowas ungewohnter als für linuxer.

Wenn Ihr wieder einen Win-Linux-Flame anfangen wollt, geht woanders hin oder tragt das per Mail aus, das interessiert hier niemanden.

ein gutes VCS lebt von benutzerfreundlichkeit und weniger von technischen feinheiten unter der haube.

Zur Benutzerfreundlichkeit gehört auch, einfach branchen und mergen zu können. Wie kaputt die meisten zentralisierten VCS sind, merkt man an vielen Einschränkungen, an die man sich als langjähriger User meist so sehr gewöhnt hat, dass man sie schon gar nicht mehr wahrnimmt.

was meinst du mit ständig 'ständig'? pro programmzeile ein 'commit'? *fg*

Das variiert von Projekt zu Projekt. Pro sinnvoller Änderung ein Commit ist üblich, wobei die Granularität projektabhängig ist.

oder eine einzelne datei, das würde bestimt auch gehen. ich kann nicht einschätzen, was hiervon vorteilhafter ist.

Eine einzelne Datei wird sehr schnell sehr unsauber. Ein Verzeichnis ist genau richtig.

nman

drakon schrieb:

Die Kontras sind imo nicht wirklich Nachteile direkt von Git gegenüber SVN.

Ich verwende ohnehin schon Git. Aber die meisten potentiellen User interessiert es weniger, wessen Schuld was ist, die wollen eher wissen, mit welchen Schwierigkeiten sie zu rechnen haben.

Ein weiterer solchen "unfairen" Grund ist auch die Möglichkeit Projekte auf einem anderen Server zu hosten. Da wird es auch mehr Möglichkeiten für SVN geben, als für Git. Ist aber imo nur eine Frage der Zeit, bis sich das durchsetzt. (Auch im Businessbereich).

Ach, mittlerweile gibts schon viele Git-Hoster. Und das werden sehr schnell sehr viele werden, weil Git auch serverseitig so viel bequemer administrierbar ist. (Ich habe längere Zeit ein paar SVN-Server administriert, ich bin froh, dass ich das Zeug mittlerweile los bin. )

drakon

nman schrieb:

drakon schrieb:

Die Kontras sind imo nicht wirklich Nachteile direkt von Git gegenüber SVN.

Ich verwende ohnehin schon Git. Aber die meisten potentiellen User interessiert es weniger, wessen Schuld was ist, die wollen eher wissen, mit welchen Schwierigkeiten sie zu rechnen haben.

Jap. Absolut. Ich meinte damit eher, dass sich diese Nachteile früher oder später geben werden. Die technischen Nachteile sind oftmals kaum zu beheben. (z.B kann SVN nicht einfach mal so verteilt werden).

Dravere

rüdiger schrieb:

Du willst mich wohl in den Wahnsinn treiben!

Immer wieder gerne
Du hast mich aber ein wenig falsch verstanden. Wollte nicht GIT damit die Schuld geben, nur sagen, dass es halt verwirrend war/ist. Ich würde da aber eher msysGit oder GitExtensions die Schuld zuschieben

Aber wie es nman so schön gesagt hat:

nman schrieb:

Aber die meisten potentiellen User interessiert es weniger, wessen Schuld was ist, die wollen eher wissen, mit welchen Schwierigkeiten sie zu rechnen haben.

Habe heute nun noch TortoiseGIT ausprobiert. Diesmal hat es mir durchaus besser gefallen. Jetzt bin ich definitiv davon überzeugt, dass ich mal ein kleines Testprojekt mit GIT durchführen möchte. Ich denke sogar, dass ich schon weiss, welches das sein wird. Alles weitere wird sich danach zeigen. Danke für die Hilfe

Grüssli

EXDW

Hatte vorhin was irgendwie komisches.
Ich habe in dev an meinen Libraries geschraubt, die letzten Tests abgeschlossen und war berteit für den nächsten "Release".
Der vorgang war bisher immer der selbe dafür, also unter SVN.

- Version in der cs erhöhen.
- Änderungen in die Changelog eintragen.
- Alles in dev submitten.
- Nach main zurück mergen.
- Labeln mit der Version
- exe Bauen und publizieren.

Nun war es in Git so, ich submitte alles nach dev, und switche zu main, dann sag ich in main, Merge from dev.
Dann kahm ne komische Message box, dort las ich dann am ende das nichts submitted wurde.
Die Ordner waren auch als geändert markiert.
Ich war es von SVN gewohnt das ich nun submitten muss, also es passte von der gewöhnung her.
Geh dann also auf submit to main, und da seh ich -> Keine änderungen.
Habe mit die Logs angeschaut, dort ist der letzte submit für dev und main eingetragen und es existiert noch ein "änderungen an den dateien".
Dem war aber nicht so, habe alles überprüft, die Dateien wurden anscheinend korrekt nach main submitted beim mergen, nur der Ordner zeigte wieder änderungen die nicht da wahren, ein Revert änderte die markierung wieder wie erwünscht, habe danach die Dateien geprüft und alles war wie erwartet sodas ich dann Labeln konnte.
Ich fand das nur sehr komisch das ganze....

ALso bisher hatte ich mit Git:
2x Wurde mit bereits änderungen an den Dateien markiert wo keine wahren (auch Explorer neustart brachte nichts)
1x Wurde mir gesagt das nach dem Merge nichts submitted wurde obwohl es doch geschah

nman

CSL schrieb:

2x Wurde mit bereits änderungen an den Dateien markiert wo keine wahren (auch Explorer neustart brachte nichts)

Das dürfte ein TortoiseGit-Bug sein, das hat mir ein Kollege auch schon berichtet.

1x Wurde mir gesagt das nach dem Merge nichts submitted wurde obwohl es doch geschah

Die genaue Abfolge und genaue Fehlermeldung wäre hierfür interessant. Vielleicht können wir ja irgendwelche Missverständnisse aufklären.

EXDW

Leider kenn ich den genauen Inhalt der Message Box nicht mehr, ist dies irgendwo nieder geschrieben?
Es sah aus wie ein report, etwas kryptisch für Windows user, ich las aber in der letzten zeile das nichts submittiert wurde.

Steps:
- Letzte änderung nach dev submitted,
- Nach master Branch geswitcht,
- "Merge" aufgerufen, dort dann dev ausgewählt,
- Message Box erscheint
- Ordner ist als geändert markiert wobei alles normal submitted wurde,
- "Revert" aufgerufen damit die Ordner wieder korrekt aussehen (und das vertrauen wieder da ist),
- Dateien geprüft ob auch alles vorhanden ist (dem war auch so),
- Gelabelt mit der neuen Version,

Von Subversion bin ich es gewohnt das die Dateien nach dem Merge noch manuell submitted werden müssen.

//Dazuedit
Im Reflog finde ich den Wortlaut der letzten Zeile:
"Fast forward (no commit created; -m option ignored)"
ist als Aktion "Merge dev" eingetragen.