SmartGit

[rüdiger]

Ein separates GUI-Tool für Versioncontrol klingt unnötig umständlich. Allein schon, wenn man zwischen Branches wechselt, dann hat man in der IDE ja Probleme, dass auf einmal alle Dateien geändert sind. Wenn VC in der IDE integriert ist, dann kann die dies je erkennen und die Dateien automatisch neu laden, ohne jedes mal nachfragen zu müssen. Außerdem hat man die gewohnten Tools, also Diff-Viewer, Merger, Editor.

Und die SmartGit Entwickler geben auch nicht wirklich einen Grund an, warum SmartGit nun besser ist, als andere Tools: http://www.syntevo.com/smartgit/why.html

Es ist nur so, dass DVCS noch ein ziemlich junges Konzept ist und die allerersten Implementierungen wie git, mercurial oder bazaar noch entsprechende Kinderkrankheiten haben, auch im Design. veracity ist da imo schon einen Schritt weiter.

git, mercurial und bazaar sind mindestens zweite Generation DVCS-Systeme. Bazaar ist zB der Nachfolger von GNU/Arch. Git und Mercurial wurden ja entwickelt, weil BitKeeper keine kostenlosen Clients mehr bereitstellen wollte. Git wurde von Monotone inspiriert und selbst für Subversion gab es mit SVK ein DVCS. Von den Features klingt es jetzt auch nicht sonderlich revolutionär (In der Liste sind ja ziemlich uninteressante Features. SHA-1 vs SHA-2? Wen interessiert's?). Das mit dem Bugtracker klingt nett (so was gibt es übrigens auch in Fossil).

Insgesamt wäre ich aber sehr vorsichtig damit, ein noch ziemlich junges VCS zu benutzen. Da ist die Gefahr einfach recht groß, da ist die Gefahr einfach recht groß, dass man auf einen unangenehmen Bug stößt.

[SideWinder]

Ich nutze schon TortoiseHg für Mercurial da ich hin und wieder auch außerhalb der IDE damit zu tun habe.

Welche Vorteile bietet SmartGit eigentlich in Bezug auf Tortoise*? Das mit dem Speed kann ich nicht bestätigen.

MfG SideWinder

[pumuckl]

lolalter schrieb:

pumuckl schrieb:

lolalter schrieb:

kannst du mir mal verraten, wozu du mehr als ein working directory brauchst?

z.B. für Vergleichsläufe, wenn ich parallel zwei unterschiedliche Versionen meines Programms debugge.

aha. und wer hindert dich daran, dein remote repo zweimal zu clonen? dann kannst du zwei branches separat auschecken, hast zwei working directories und kannst parallel zwei branches entwickeln + debuggen, wenns denn sein muss.

Genau, und um den einen branch in den anderen zu mergen muss ich den ganzen Mist erst übers remote repo stopfen. Offline arbeiten geht dann wieder nur beschränkt, damit kann ich mir git schon fast wieder sparen.

lolalter schrieb:

pumuckl schrieb:

Abgesehen davon ist das mit den push Rechten bei git auch sone Sache - die gibts da nicht, git hat AFAIK keine User- und Rechteverwaltung, man muss das Ganze stattdessen durch entsprechende Zugriffsrechte auf den Server emulieren. Noch ein Vorteil für Veracity

nein. du musst dem ssh user lediglich schreibrechte entziehen. schon kann er nur noch lesen. das ist in zig open source projekten usus. du kannst dir das repo clonen, aber nicht direkt pushen.

Sage ich ja. Die Rechteverwaltung ist außerhalb des Systems und nur recht grobschlächtig, weil sie die die verschiedenen Möglichkeiten im DVCS nicht kennt, nur lesen/schreiben.

lolalter schrieb:

pumuckl schrieb:

Ich will weder git schlechtreden noch halte ich veracity für den heiligen Gral. Es ist nur so, dass DVCS noch ein ziemlich junges Konzept ist und die allerersten Implementierungen wie git, mercurial oder bazaar noch entsprechende Kinderkrankheiten haben, auch im Design. veracity ist da imo schon einen Schritt weiter.

GIT gibts mittlerweile seit 6 jahren. imo ist es sehr ausgereift. kinderkrankheiten sehe ich keine. nur weil du den sinn von rebase nicht siehst, heisst es nicht, dass es keinen gibt.

Dann nenn mir einen. Ich lerne gerne. Aber bitte einen, der wichtig genug ist, um das Risiko einer vermurksten DAG-History zu rechtfertigen. Nochmal: Ich sage nicht, dass git schlecht ist. Nur fehlen mir ein paar features, an die man vermutlich beim Design nicht gedacht hat, eben weil die Idee von DVCS bei der Entstehung von git noch relativ neu war und die Implikationen z.B. fürs Bugtracking noch nicht so bekannt waren.

lolalter schrieb:

GIT ist extrem weit verbreitet. alleine github hostet mittlerweile unzählig viele bekannte open source projekte und hat über 1 mio user.
von veracity habe ich hingegen noch nicht mal was gehört.

Dass viele open-source Projekte git benutzen ist schön und gut. Allgemein werden die moderneren Werkzeuge vor allem bei open-source-hobby-geeks am ehesten akzeptiert, daher ist das kein Wunder. Aber wie schauts mit der Industrie aus? Warum ist nach 6 Jahren dort die Akzeptanz noch so gering?

rüdiger schrieb:

Das mit dem Bugtracker klingt nett (so was gibt es übrigens auch in Fossil).

Jup. Als ich nach DVCS mit Bugtracking gesucht hab, kamen auch nur Fossil und Veracity als Ergebnis. Fossil hat mir auf den ersten Blick nicht so gefallen...

rüdiger schrieb:

Insgesamt wäre ich aber sehr vorsichtig damit, ein noch ziemlich junges VCS zu benutzen. Da ist die Gefahr einfach recht groß, da ist die Gefahr einfach recht groß, dass man auf einen unangenehmen Bug stößt.

Ich hab mir mal die Testsuite angeschaut, die SourceGear auf das Ding loslässt, und ich muss sagen, die sind echt schonungslos. Die machen nicht nur alles, was man mit dem Ding machen kann, die machen auch alles, was man NICHT machen sollte - prügeln es grün und blau und checken dann, dass es auch mit den richtigen Knochenbrüchen liegen bleibt

Okay, ich sollte aufpassen, dass ich nicht zum fanboy werde

[Fast2_unreg]

Rebase ist da, falls es mal jemand nutzen möchte, so sehe ich das.

Natürlich muss man in dem Fall wissen, was man tut (das muss man oft ), aber der Rest kann es schlichtweg ignorieren.
Vergleiche es doch mit goto oder ähnlichem in C++.
Manche Sachen braucht man vielleicht sehr selten, aber falls doch, ist man schon froh, dass es sie gibt.
Viele sind bestimmt auch bereit das Risiko einzugehen, und im Gegenzug eine schöne Chronik zu bekommen – man kann ja zuvor auch das relevante aus .git, vielleicht auch noch wichtige Dateien, manuell über das Dateisystem sichern, so ist es ja nicht
Wenn es schiefläuft, einfach die Dateien ersetzen und nochmal probieren (oder es sein lassen).

Noch meine allgemeine Meinung zu Git:
Am Anfang erschien mir das Konzept merkwürdig, aber nachdem ich es verstanden hatte, fand ich es ziemlich gut.
Das einzige, was mich – wie anscheinend auch viele andere – bisher wirklich gestört hat, ist, dass es keine Nutzer gibt.
Mit den Berechtigungen des Ordners rumzuhantieren, ist nicht so toll, vor allem aus dem bereits genannten Grund, dass das Dateisystem nichts von den verschiedenen Befehlen weiß.

Viel schöner wäre es, z.B. verschiedenen Gruppen direkt in Git nur Zugriff auf bestimmte Branches geben zu können (weil sie genau dafür zuständig sind), oder nur Zugriff auf bestimmte Ordner (gut, das ginge auch mit dem DS), oder auch für Anfänger beispielsweise Rebase, das Böse schlechthin (mit anderen Kommandos kann man sicherlich mehr Schaden anrichten, dass ich über sie gelesen habe ist aber schon etwas her, werde ich bei Gelegenheit, und wenn ich Git mal wieder brauche, vielleicht auffrischen.

[lolhehe]

rebase ist durchaus ein nützliches tool und auch überhaupt kein problem, so lange man damit nicht die commit history ändert, die man bereits in einen remote branch gepusht hat, mit dem andere arbeiten.

das berechtigungssystem finde ich extrem gut. es ist einfach und simpel und trotzdem kannst du damit riesige projekte gut organisieren. bei kleinen teams hat idr ja sowieso jeder schreibrechte für alles. bei großen projekten haben halt nur bestimmte leute schreibrechte. es kann sich aber trotzdem jeder mit leserechten beteiligen. er muss ja einfach nur das repo clonen und jemanden mit schreibrechten bitte, die änderungen aus clone ins remote repository zu pullen. das ganze hat noch den vorteil, dass man so auch extrem gut code reviewing betreiben kann.

wers genauer wissen will, sollte progit kap. 5 lesen: http://progit.org/book/ch5-1.html

[Shade Of Mine]

pumuckl schrieb:

Als ich nach DVCS mit Bugtracking gesucht hab, kamen auch nur Fossil und Veracity als Ergebnis. Fossil hat mir auf den ersten Blick nicht so gefallen...

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

PS:
rebase ist dafuer da die commit history sauber zu halten.
Du arbeitest an einem feature und hast logischerweise 50mio commits - aber irgendwann ist das feature fertig. dann mergt du das features in den master branch und dank rebase hast du dann nur noch die wichtigen commits drinnen. weil es recht uninteressant ist dass du 20mal die types.h geandert hast weil du zwischen int und short gewechselt bist bis das feature komplett war.

ist natuerlich nicht ein killer feature und man kann auch ohne rebase leben, ich habe es noch nie gebraucht, war aber auch noch nie in so einer situation wo ich features unabhaengig vom master branch entwickelt habe.

[KuhTee]

Shade Of Mine schrieb:

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

Schon lustig. Denn argumente, die in diesem thread gegen smartgit aufgeführt wurden, waren in erster linie ja "Ich mag es nicht wenn die Sachen getrennt sind.". Auch von dir, gleich im ersten antwort post.

[lolhehe]

ich sehe überhaupt keinen grund darin, vcs und bugtracking zu kombinieren. denn bugtracking systeme nutzen ja nicht nur entwickler, sondern je nach projekt auch noch ganz andere personenkreise (PL, QS, keyuser, kunden etc). niemand von denen sollte auch nur in die nähe des vcs kommen!

mir reicht ne lose kopplung zwischen vcs und bugtracking vollkommen aus, indem man z.b. die task nummer in den commits oder branches referenziert. github hat darüber hinaus auch noch nette service hooks zu jira und co.

[EXDW]

TFS macht das sehr geschickt mit dem SCM -> Work items.

[pumuckl]

lolhehe schrieb:

ich sehe überhaupt keinen grund darin, vcs und bugtracking zu kombinieren. denn bugtracking systeme nutzen ja nicht nur entwickler, sondern je nach projekt auch noch ganz andere personenkreise (PL, QS, keyuser, kunden etc). niemand von denen sollte auch nur in die nähe des vcs kommen!

Warum nicht - wenn sie nur bei den Bugs Schreibrechte haben und sonst nicht, ist das doch kein Problem

Ein Grund, Bugtracking mit dem VCS zu kombinieren:
Nehmen wir an, Projekt X hat 5 branches. Ist bei DVS eher die Regel als die Ausnahme. Ein Bug taucht auf (Branch A), der Tester trägt ihn in den zentralisierten Bugtracker ein. Wenn ich Glück habe noch mit dem Hinweis, in welchem Branch er aufgetaucht ist. Ich fixe den Bug auf Branch A und trage das in den Bugtracker ein.
Einen Monat später. Der Bug taucht auf Branch B auf. Der andere Tester findet im Bugtracker den Eintrag und weiß, der Bug ist im Grunde gefixt. Nur warum ist er auf Branch B noch vorhanden? Und auf welchen anderen Branches? Im Bugtracker steht nicht, wo der Fix schon überall reingelaufen ist. Die Entwickler wissen erst recht nicht, auf welchen ihrer Branches der Bug noch vorhanden ist (schließlich haben sie andere Branches als der zentrale Server). Wenn der Fix aber zusammen mit dem Eintrag im Bugtracker im verteilten System liegt, dann wird der Eintrag "Bug gefixt" immer zusammen mit den Fixes auf die verschiedenen Branches gemerget.

Shade Of Mine schrieb:

rebase ist dafuer da die commit history sauber zu halten.
Du arbeitest an einem feature und hast logischerweise 50mio commits - aber irgendwann ist das feature fertig. dann mergt du das features in den master branch und dank rebase hast du dann nur noch die wichtigen commits drinnen. weil es recht uninteressant ist dass du 20mal die types.h geandert hast weil du zwischen int und short gewechselt bist bis das feature komplett war.

Den branch für das Feature brauche ich nirgendwohin zu pushen. Im Master branch gibts nur den einen dicken Commit, mehr sieht der zentrale Server und meine Kollegen nicht. Aber wenn ich später dann merke, dass ich vielleicht doch short statt int hätte nehmen sollen, bin ich froh, wenn ich die History noch hab.

[Shade Of Mine]

KuhTee schrieb:

Shade Of Mine schrieb:

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

Schon lustig. Denn argumente, die in diesem thread gegen smartgit aufgeführt wurden, waren in erster linie ja "Ich mag es nicht wenn die Sachen getrennt sind.". Auch von dir, gleich im ersten antwort post.

Nein.
Das sind 2 unterschiedliche Sachen.

Unterschiedliche Tools koennen trotzdem integriert sein. Eine IDE ist ja nichts anderes als eine Sammlung an Tools die sich miteinander integrieren. Daher auch der Name. Da gibt es Plugins die es ermoeglichen mehr Features zu haben -> zB eben Version Control.

Aber wenn das VCS nicht gut ist, nehme ich ein anderes Plugin. Darum geht es.

Integriert muessen die Tools miteinander aber dennoch sein. Ein Commit muss ein Ticket schliessen koennen. Aber dazu muss das Ticketing System nicht zwangslaeufig ein Teil des VCS sein.

[lolhehe]

sehe ich ähnlich. wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

was habe ich denn davon? spart es zeit? nicht wirklich. wenn ich 8h an einem task programmiert habe, breche ich mir sicher keinen zacken aus der krone, wenn ich noch manuell im bugtracker den task schließe, kommentiere oder jemand anderem zuweise. evtl. muss ich ja auch noch meine zeit dort buchen oder die versionsplanung machen für den nächsten release oder oder oder... alles sachen, die nix mit vcs zu tun haben.

solche eierlegenden wollmilchsau tools sind selten toll. was ist denn, wenn man morgen doch einen anderen bugtracker braucht, weil das tool nicht mehr alle anforderungen erfüllt? dann muss man sich gleich auch noch ein anderes vcs suchen. tolle wurst...

github hat btw. ungefähr 238949349 service hooks zur git integration mit anderen diensten, darunter auch viele bugtracker wie jira oder bugzilla.

[mezzo mix]

lolhehe schrieb:

wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

habe mich beim lesen von Shade of Mines kommentar allerdings auch gefragt, wie man vor dem commit sinnvoll testet und sich seinem ergebniss sicher sein kann, ausser man frickelt alleine an seiner software. zumal der entwickler den bug-report in der regel nicht selbst geoeffnet hat und deshalb auch nicht entscheiden sollte, wann er zu schliessen ist.

[EXDW]

Bei uns im TFS (Firma hat so 230 Leute) läuft es so:
- <Irgendwer> kommt daher und macht ein Work Item (Bug) auf
- Ein Entwickler Triaged das Problem (ist es wirklich eins, tritt es immer auf usw) und setzt es auf "In Progress" (evtl noch ein Assignment)
- Ein Entwickler behebt das Problem und Committed es zu dem Work Item (Changeset mit Branch und alles ist dadurch bekannt)
- Er schreibt in das Work Item rein was das Problem war und wie er es behoben hat
- Er setzt das Work Item auf "Ready for Test"
- Ein GM wird gebaut und sammelt alle Work Items welche dort rein flossen (Bugs, Tasks, Requests)
- <irgendwer> verifiziert alle angesammelten Work Items zu diesem GM
- Wenn nicht behoben wird es wieder Reopen mit ein Comment
- Wenn nicht wird es Close

Dadurch hat man im Work Item direkt das Changeset assoziiert, man kann rein sehen welche Dateien für den Fix angefasst wurden.
Man kann die History des Work Items durch sehen und jedes Changeset diffen, direkt öffnen usw - ohne das man manuell Sachen hin und her kopieren muss.

Continuous Integration ist dadurch sehr einfach.
Z.B. läuft ein Build automatisch sobald zu ein paar Work Items was assoziiert wurden (oder gar bei jeder Assoziierung), und hat direkt alle Informationen beisammen was in den Build rein floss.

"Oh, ein neues Build - mal schauen - OK, Bug 1, 4, 9 und 15 sind darin gefixt wurden, das kann ich Testen"
Das geht alles Automatisiert ohne das ein Mensch die Comments noch durch lesen muss ^^

[lolhehe]

wir arbeiten so (tools: git, github, jira):

- bugs, features und change requests werden in Jira erfasst
- der jeweilige teamleiter macht die release planung: welche task wird in welcher version gemacht?
- während des sprints werden die tasks für die kommende version bearbeitet
- der entwickler legt sich einen branch an, z.b. task-123 (der master branch ist immer stabil und kann deployed werden)
- features branches werden ins zentrale repository gepusht (github)
- wenn das feature fertig ist oder wenn der entwickler feedback von anderen entwicklern braucht, erstellt er einen pull request für den branch
- jeder entwickler hat jederzeit einblick in alle pull requests und kann kommentare und verbesserungsvorschläge schreiben
- sobald das feature fertig ist, gibt es ein finales code review des jeweiligen teamleiters. wenn alles ok ist, werden die änderungen aus dem feature branch in den master branch gepullt
- von jedem branch kann jederzeit mit einem befehl eine testversion gebaut werden
- mit einem jira service hook kann der status einer task in jira per commit geändert werden (z.b. status auf gelöst setzen)
- continous integration server testet und baut alles, was in die master branches gepusht wird

ich sehe nicht, wo stärkere integration des bugtrackers ins vcs hier arbeit erleichtern sollte.

[Shade Of Mine]

mezzo mix schrieb:

lolhehe schrieb:

wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

habe mich beim lesen von Shade of Mines kommentar allerdings auch gefragt, wie man vor dem commit sinnvoll testet und sich seinem ergebniss sicher sein kann, ausser man frickelt alleine an seiner software. zumal der entwickler den bug-report in der regel nicht selbst geoeffnet hat und deshalb auch nicht entscheiden sollte, wann er zu schliessen ist.

Naja, ist halt die Frage wie gross deine Software ist. Bei uns arbeiten vielleicht 3 Leute daran wenn es mal viel sind. Da ists sehr leicht sowas zu machen.

Ausserdem sollte man sowieso einen Test fuer einen Bug haben, wenn der Bug reproduziert werden kann, kann er mit einem Testcase als geschlossen bewiesen werden.

Wenn man natuerlich oeffentliche Bugtracker hat, ists komplizierter.

Aber ich habe dennoch explizit Ticket und nicht Bug gesagt. Denn ein Ticket kann weitaus weniger kompliziert als ein Bug sein. Ein Ticket kann zB "Kommentare in Datei foo.hpp fixen" sein.

Weiters muss man nicht zwangslaeufig ein Ticket schliessen mit einem commit, aber man sollte ein commit an ein Ticket haengen koennen. Das ist oft praktisch.

Je nachdem wieviel Leute mitarbeiten braucht man natuerlich unterschiedliche Abstraktionsebenen. Dann muss ein commit zB anstossen koennen dass jemand das Ticket neu begutachtet und schaut ob es jetzt geschlossen werden kann.

Wir sind wenige Leute, deshalb machen wir alles selber Bei 230 Programmieren wird alles natuerlich komplizierter...

[lolhehe]

Shade Of Mine schrieb:

Weiters muss man nicht zwangslaeufig ein Ticket schliessen mit einem commit, aber man sollte ein commit an ein Ticket haengen koennen. Das ist oft praktisch.

jo. wobei es imo schon ausreicht, die task nummer in die commit message zu schreiben. wenn man den task später noch mal bearbeiten muss, kann man ja einfach die commit history durchsuchen.