SmartGit
-
Wenn du keine IDE integration willst, würde ich Smart* nehmen. Damals war SmartSVN auch das beste Tool das wir gefunden haben. Gerade bei Git kann ich mir kaum vorstellen dass es da eine größere Auswahl gibt.
Wichtig ist halt, dass nicht die Foundation Edition sondern die kommerzielle verwendet wird.
-
kenne smartgit nicht, aber fänds total umständlich, zusätzlich zur IDE noch ein extra tool für git zu benutzen. es ist doch viel praktischer, wenn man direkt die IDE als mergetool zum lösen von konflikten benutzen kann bzw. diffs direkt im code editor der IDE sieht.
benutze intellij idea und das hat ne sehr gute GIT integration (vor allem ab version 11). alles weitere mache ich direkt per bash.
-
Shade Of Mine schrieb:
Wichtig ist halt, dass nicht die Foundation Edition sondern die kommerzielle verwendet wird.
Na sicher. Bei 60$ pro Platz ist das auch kein Thema. Nicht mal für unseren Sparfuchs von Chef.
Beim Einsatz in der Firma bleibt einem auch keine andere Wahl, die kostenfreie Version ist nur für nichtkommerziellen Einsatz.Noch ist ja nichts entschieden. Was würdest du für git empfehlen, wenn ich doch mal ein in die IDE integriertes Tool ausprobieren möchte?
-
Ich bin auf bestem Wege, mich von git zu verabschieden. Unter anderem, weil einige der Designentscheidungen für mich unglücklich gewählt sind (nur ein working directory pro Repo, die Möglichkeit, die History nachträglich zu verändern per rebase, ...). Außerdem hat mein neuer Liebling einen verteilten Bugtracker integriert, d.h. man kann Bugs wirklich parallel zu den Bugfixes verwalten, statt zentralisiert. Das gute Stück heißt veracity, ist open source, allerdings noch in der Entwicklung (wobei die nötigen DVCS-Features allesamt implementiert sind). Enthalten ist ein tortoise-artiges shell-Plugin, html-gui für die Bugverwaltung (sie nennen es work items) und einiges mehr. IDE-Integration soll kommen, wird aber dann kostenpflichtig sein.
-
kannst du mir mal verraten, wozu du mehr als ein working directory brauchst?
mit rebase kann man in der tat böses anstellen, aber wenn ich jemandem push rechte für mein repo gebe, dann gehe ich davon aus, dass er weiss, was er tut.
und im zweifel kann man auch einfach immer mergen, der snapshot ist der gleiche...
-
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.
lolalter schrieb:
mit rebase kann man in der tat böses anstellen, aber wenn ich jemandem push rechte für mein repo gebe, dann gehe ich davon aus, dass er weiss, was er tut.
und im zweifel kann man auch einfach immer mergen, der snapshot ist der gleiche...History ist history, und den DAG zu ändern widerspricht dem eigentlichen Konzept dahinter. Bei DVCS bringts außerdem unnötige Gefahren mit sich, für ein Feature, das man im Grunde nicht braucht. 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
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.
-
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.
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. stattdessen schickst du ein patch per email oder pusht in deinen privaten fork und der owner pullt die änderungen von dort.
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.
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.
-
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.
-
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
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
TFS macht das sehr geschickt mit dem SCM -> Work items.
-
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.
-
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.
-
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.
-
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.