Wer von euch benutzt SVN (o.Ä.)?
-
ich benutze svn nur über die Kommandozeile. Weiß nicht, was schwer an 'svn ci/up' sein soll
-
ich bin git fanboy
-
sothis_ schrieb:
ich bin git fanboy
Und somit bist du offtopic.
-
frenki schrieb:
Ich benutze auch (noch?) SVN, bin aber nicht besonders zufrieden. Die Performance ist unter aller Sau sobald das Projekt grösser wird. Und mal eben einen Bugfix aus dem Trunk in's letzte Release backzuporten ist ein dermassener Krampf dass ich es dann doch lieber von Hand mache.
Ich nutze TortoiseSVN als Frontend. Auf der Suche nach einem Ersatz für SVN kommen auch nur solche in Frage für die es ein gutes GUI-Frontend für Windows gibt. Kommandozeile war vorgestern...
Lol
Beim programmieren gibst du aber schon noch Text ein, oder klickst du dir den Code mit lustigen Buttons & Dialogen zusammen?
-
Beim programmieren gibst du aber schon noch Text ein, oder klickst du dir den Code mit lustigen Buttons & Dialogen zusammen?
Naja, man kann eine IDE verwenden oder einfach nur edit.exe und den Compiler mit all seinen Optionen per Hand aufrufen. Was mag da wohl wirtschaftlicher sein. (Sicherlich edit.exe weil bereits vorhanden, geht keine Zeit verloren für die Installation einer IDE ^^)
-
Offtopiv schrieb:
sothis_ schrieb:
ich bin git fanboy
Und somit bist du offtopic.
was verstehst du an "o.ä." nicht?
-
Knuddlbaer schrieb:
Beim programmieren gibst du aber schon noch Text ein, oder klickst du dir den Code mit lustigen Buttons & Dialogen zusammen?
Naja, man kann eine IDE verwenden oder einfach nur edit.exe und den Compiler mit all seinen Optionen per Hand aufrufen. Was mag da wohl wirtschaftlicher sein. (Sicherlich edit.exe weil bereits vorhanden, geht keine Zeit verloren für die Installation einer IDE ^^)
-
Ich verwende Subversion mit TortoiseSVN und VisualSVN fürs Studio.
Letzteres kostet zwar was, ist aber IMO 100x besser als das total lästige, langsame und verbuggte AnkhSVN.Subversion hauptsächlich weil wir es in der Arbeit verwenden, weil es für Windows mit TortoiseSVN ein absolut geniales Frontend gibt, und weil es das beste der Systeme ist die halbwegs breit unterstützt werden (also auch bei open-source-gratis-hostern wie sourceforge).
Wenn ich rein nach den Features des "Core-Systems" gehen würde (also ohne Frontend etc.) würde ich sicher nicht mit Subversion arbeiten, sondern vermutlich mit einem System welches auch so vollkommen abstruse und kaum-jemals-gebrauchte Dinge wie "Rename" versteht
Und nicht ganz SO langsam ist.
-
Dann benutz doch einfach GIT, es gibt kein besseres VCS.
-
GIT ist nicht serverbasiert.
Und "keiner" unterstützt es.Wie es mit Frontends aussieht kann ich nicht sagen, schätze aber Klickibunti-GUIs für Windows ala TSVN wirds nicht spielen. Und sowas will ich, interessiert mich genau überhaupt nicht für ein VCS nochmal irgendwelche blöden commandline Befehle zu lernen.
Falls doch... toll, bleiben für mich aber immer noch die 2 ersten Probleme.
-
hustbaer schrieb:
GIT ist nicht serverbasiert.
auch wenn es dezentralisiert ist, ist es sehr wohl möglich ein 'haupt' repository auf einem server einzurichten.
hustbaer schrieb:
Und "keiner" unterstützt es.
für mich als privatentwickler reicht das angebot von repo.or.cz. daneben unterstützen es noch savannah, github, alioth und noch einige kleinere andere hoster.
hustbaer schrieb:
Wie es mit Frontends aussieht kann ich nicht sagen, schätze aber Klickibunti-GUIs für Windows ala TSVN wirds nicht spielen. Und sowas will ich, interessiert mich genau überhaupt nicht für ein VCS nochmal irgendwelche blöden commandline Befehle zu lernen.
Falls doch... toll, bleiben für mich aber immer noch die 2 ersten Probleme.
qtgit, git-gui, usw.. zugegebenermaßen noch nicht mit tortoisesvn zu vergleichen, aber das wird noch
-
hustbaer schrieb:
GIT ist nicht serverbasiert.
Gerade das es ein dezentrales VCS ist sehe ich als riesen Vorteil an. Es ist so schön alleine ein wenig rumprobieren zu können und trotzdem das ganze Rumprobieren unter Versionskontrolle zu stellen und jederzeit zu älteren Experimentierstadien zurückkehren zu können ohne andere im Team damit zu belästigen. Und wenn irgendjemand den vielleicht noch nicht wirklich ausgereiften Stand von dem Teil braucht, den ich gerade bastel, kann er sich ihn einfach von mir ziehen ohne dass ich den Stand auf einen zentralen Server schieben muss, wo ich jeden mit meinem Kram belästige.
...
-
Na, das kannst du doch auch mit z.B. SVN haben: einfach einen eigenen Branch anlegen und "rumspielen", wie du willst. Und wenn du meinst, das du den nicht commiten mußt (auch nicht auf deinen eignen Branch), machst du ein Revert. Ich sehe bisher keinen nennenswerten Vorteil von einen dezentralen System, was diese Arbeitsweise angeht.
-
Wenn du so arbeiten würdest, wie du es mit einem dezentralen System tust hättest du ruck zuck unmengen von Branches und alle liegen öffentlich auf dem Server und keiner weiß mehr was was ist.
Ich mache einen Branch und "foo" beschreibt, was ich da gerade ausprobiere, also nenne ich ihn "foo". Jemand anderes macht auch ein Experiment und es würde ebenfalls gut durch "foo" beschrieben. Er kann sein Experiment aber nicht "foo" nennen, weil das ist ja schon mein Experiment. Also muss er sich was anderes ausdenken => nervt. Eigentlich soll weder er und noch sonst jemand was von meinem Experiment "foo" mitbekommen, aber ich muss damit den Server zumüllen.
Hast du jemals wirklich exzessiv gebranched/merged mit SVN? Hast du es jemals eingesetzt, einfach nur für ne kleine Spielerei? Nein? Ich jedenfalls nicht und ich kenne auch niemanden. Dezentrale Systeme können die Arbeitsweise ganz schön verändern.
Es gibt tonnenweise Dinge. Du arbeitest auf nem Laptop im Zug ohne Internetzugang und kannst trotzdem immer committen, wieder zurückgehen, etc.
-
Helium schrieb:
Wenn du so arbeiten würdest, wie du es mit einem dezentralen System tust hättest du ruck zuck unmengen von Branches und alle liegen öffentlich auf dem Server und keiner weiß mehr was was ist.
Man kann mit jedem System Chaos machen. Und genauso kann man mit SVN auch recht geordnet arbeiten, z.B. indem man jeden User seinen "/branches/user/fritz" Ordner gibt wo er sich austoben kann. Wenigstens bekommt man so mit wo wer an was arbeitet, kann jederzeit reingucken (egal ob der Rechner des entsprechenden Users nun gerade läuft oder nicht, oder wieder irgendein spezial-Keks auf die Idee gekommen ist irgendeine doofe Firewall zu installieren, so dass man nicht auf seinen PC zugreifen kann), kann sich den Code ansehen etc. - und dem entsprechenden User ggf. eins auf den Zutz geben. Ich persönlich finde das auch angenehmer als wenn man sich zu den Repositories jedes Users einzeln connecten müsste um nachzusehen was der gerade anstellt. Aber egal. Wichtig ist nur: man kann auch mit Subversion organisiert arbeiten.
Ich mache einen Branch und "foo" beschreibt, was ich da gerade ausprobiere, also nenne ich ihn "foo". Jemand anderes macht auch ein Experiment und es würde ebenfalls gut durch "foo" beschrieben. Er kann sein Experiment aber nicht "foo" nennen, weil das ist ja schon mein Experiment. Also muss er sich was anderes ausdenken => nervt. Eigentlich soll weder er und noch sonst jemand was von meinem Experiment "foo" mitbekommen, aber ich muss damit den Server zumüllen.
Siehe oben. Und was das "zumüllen" angeht: ich sehe eher einen Vorteil darin dass diverse Dinge nicht einfach nur im lokalen Repository eines Users rumlungern, sondern "öffentlich sichtbar" sind, und auch gegen Dummheit ("upps, jetzt hab ich mein GIT Repository gelöscht, so ein Pech") gesichert sind. Der Nachteil ist natürlich dass sämtliche Experimente auf Immer und Ewig Platz im Repository brauchen -- zumindest bei SVN.
Hast du jemals wirklich exzessiv gebranched/merged mit SVN?
Definiere exzessiv. Davon abgesehen: ich hab' nie behauptet dass SVN so toll wäre was branchen/mergen angeht. Gerade der nicht vorhandene Rename-Support macht das oft zu einem Krampf. Dass SVN schweinelangsam ist (was ich auch schon angesprochen habe) nervt da auch. Und die merge-(un)logik von SVN ist auch nicht die beste. Hat aber alles nix mit zentral/dezentral zu tun. Die gleichen Probleme hätte SVN vermutlich auch wenn es dezentral wäre, bzw. hätte GIT vermutlich auch nicht wenn es zentral wäre.
Hast du es jemals eingesetzt, einfach nur für ne kleine Spielerei? Nein? Ich jedenfalls nicht und ich kenne auch niemanden.
Jo, eigentlich schon. Und ich kenne auch zumindest noch einen ausser mir
Dezentrale Systeme können die Arbeitsweise ganz schön verändern.
Glaub ich dir sofort. Trotzdem bin ich nicht davon überzeugt dass z.B. für unsere Firma dezentral die bessere Lösung wäre. Dass es nur einen Server gibt, und man Dinge auf genau diesem einen Server einchecken MUSS (wenn man sie überhaupt irgendwo "sichern" will) hat auch Vorteile.
Es gibt tonnenweise Dinge. Du arbeitest auf nem Laptop im Zug ohne Internetzugang und kannst trotzdem immer committen, wieder zurückgehen, etc.
Ja klar ist das cool. Trotzdem würde ich ein rein dezentrales System nicht in der Arbeit einsetzen wollen. Dann noch lieber ein rein zentrales System wie SVN.
Noch lieber wäre mir ein System welches die Vorteile von beiden irgendwie vereint, und nochdazu die ganzen Schwachstellen von SVN nicht hat (Rename, Mergen etc.). Und eben die entsprechenden Tools bietet. Und von Leuten entwickelt wird die nicht unentwegt "aufs falsche Pferd setzen" (WebDAV, SASL, ...). Und... naja, gibts aber leider nicht.
-
hustbaer schrieb:
Trotzdem würde ich ein rein dezentrales System nicht in der Arbeit einsetzen wollen. Dann noch lieber ein rein zentrales System wie SVN.
hä? was ist denn an git rein dezentral? ihr könntet das doch auf der arbeit exakt genauso benutzen wie svn, wenn ihr wolltet. nur kommen halt noch ein paar features hinzu.
-
hustbaer schrieb:
Ich persönlich finde das auch angenehmer als wenn man sich zu den Repositories jedes Users einzeln connecten müsste um nachzusehen was der gerade anstellt.
Man kann natürlich auch mit git alle Branches global verwalten und auf einen zentralen Server packen. Der Vorteil bei (den meisten) DVCS-Systemen ist ja, dass man trotzdem noch zentral arbeiten kann. Ich habe für meine (mini) Projekte auch immer einen zentralen Server, allein aus Backupgründen.
Im Grunde hört sich dein Beitrag so an, als hättest du nie mit einem modernen VCS gearbeitet und deine Argumente gründen auf Vorurteilen, die aus deiner Phantasie entstanden sind. Bisher kenne ich übrigens niemand, der wirklich intensiv mit git oder ähnlichen modernen VCSs geabreitet hat und danach SVN wieder benutzen wollte...
-
Vor einigen Jahren hab ich mit Visual Source Safe angefangen. Das wurde eigentlich nur als Backup-System verwendet (und mehr scheint es auch nicht zu können).
Dann bin ich zu SVN. Das war schon deutlich besser. Damit war ich auch eine zeitlang zufrieden.
Eher aus Spass heraus hab ich mal git ausprobiert. Es hat etwas länger gedauert bis ich damit zurecht kam. Jetzt will ich aber nicht mehr weg davon. Git ist angenehm und wesentlich intelligenter.
Bei SVN hab ich es einige Male geschafft den svn-Projekt-Ordner zu zerschießen. Dateien löschen, umbenennen, verschieben. Damit kommt git besser klar.
Ein kleines Spiel-Projekt ist schnell eingerichtet, was bei SVN immer etwas dauerte.Ich kann jedem nur empfehlen git auszuprobieren. Am Anfang ists vielleicht etwas ungewohnt - aber es lohnt sich.
-
Helium! Wir setzen es beruflich ein und es arbeiten an den Projekten auch mehrere Leute. Wie von hustbaer auch schon gesagt, gibt es kein Namenschaos, weil jeder User in den Branches ein User-Verzeichnis anlegen kann. Zu bedenken ist ja immer, das SVN auf einer Verzeichnis-Philosophie basiert. D.h. du kannst beliebig Verzeichnis anlegen, um eine Struktur zu erhalten. Da legt man einmal was fest und jeder kann in seinem Verzeichnis-Branch rumspielen wie er will.
Mergen tun wir natürlich auch, wenn es mal nötig ist. Aber ganz ehrlich? Meistens bekommt ja jeder eine andere Aufgabe in einem Projekt, so das die Überschneidungen selten sind. Und wenn sie denn mal vorkommen, wird halt gemerged. Wenn das mergen unverständlich wird (was ja mal vorkommen kann), dann setzen wir uns halt für fünf Minuten zusammen an einen Rechner und schauen drauf, was wie gemerged werden soll. Denn nur weil es Computer und Server gibt, heißt es nicht, das man keinen persönlichen Kontakt bei der Arbeit mehr haben darf. Ganz im Gegenteil, es wir sind foh, wenn es mal einen Grund gibt, das man sich auch mal persönlich mit dem Kollegen vor den Rechner setzt.
Und so oft kommt es wie gesagt nicht vor, das man mergen muß. Teilweise macht es ja SVN sogar automatisch, wenn es keinen Mergekonflikt gibt. (weil die Änderungen in einer Datei an unterschiedlichen Stellen sind)
SVN leistet bei uns schon sehr gute Dienste. Und das sich jeder verbarrikadiert, weil es ein Tool erlaubt, ist keine schöne Kultur wie ich finde. Wir arbeiten schliesslich gemeinsam an einem Projekt. Und niemand muß sich für seinen Code schämen... auch wenn er mal rumgespielt hat. Notfalls macht er vor dem Commit ein Revert, wenn es absolut für die Nachwelt unsichtbar sein soll.
-
hustbaer die Hälfte deiner Einwände sind doch Käse, denn die haben weniger mit GIT als mit eurer Systemorganisation zu tun. Was kann GIT dafür, wenn ihr eure Systeme nicht anständig administriert?
Die andere Hälfte dient ja nur dazu SVN zu verteidigen, das ist ok, auch wenn man objektiv sagen kann, dass GIT besser ist. Ist auch kein Wunder schließlich ist GIT neuer und es fließt somit mehr Erfahrung ein
