CVS oder SVN?
-
Zu all den "SVN reicht auch"-Posts: Natürlich kann man auch mit schlechten Werkzeugen arbeiten. Ich löte auch immer noch mit einem 10€-Lötkolben und habe ganz brauchbare Resultate. Allerdings würde ich wenn ich ohne finanziellen Aufwand für zuhause eine der hübschen Weller-Stationen, die wir auf der Uni haben, bekommen könnte ohne zu zögern eine nehmen. Meine Elektronikprojekte würden dadurch nicht zwangsläufig besser, aber die Arbeit an sich wäre definitiv angenehmer, wenn ich nicht immer ewig warten müsste, bis das Eisen heiß ist oder mich über die ungleichmäßige Temperaturverteilung und die ständig oxidierende Spitze ärgern müsste.
SolidOffline schrieb:
- git und mercurial sind besser weil: Beide System laufen lokal auf deinem Rechner und somit funktionieren beide auch dann, wenn du mal keine Internetverbindung hast. Wenn eine Verbindung besteht, kannst du die Änderungen mit dem Server abgleichen.
Aussage falsch, weil: SVN ebenfalls lokal läuft und ebenfalls auch dann bestens funktioniert, wenn keine Internetverbindung besteht.
- ... CVS und SVN beide einen Server benötigen, den Du irgendwo installieren musst, zB. bei Dir zuhause.
Aussage falsch, weil: SVN keinen Server benötigt, den man irgendwo installieren muss.
Die Aussagen sind nur dann falsch, wenn Du davon ausgehst, dass Du Dich a) beim Entwickeln immer auf einen Rechner beschränken kannst und b) immer alleine arbeitest.
Ich weiß nicht, wie häufig das bei Dir der Fall ist, aber bei mir kommt a) bei jedem Projekt irgendwann der Zeitpunkt, an dem ich gerne vom Laptop aus arbeiten möchte oder auf der Uni im Labor oä. und b) arbeite ich an der überwiegenden Mehrzahl meiner Projekte nicht alleine, weswegen Kollegen der Verweis auf den USB-Stick, auf dem mein Repo liegt, nicht viel hilft.
Dravere: Dass der Einstieg mit Mercurial leichter ist, als mit Git, würde mich nicht wundern. Ich habe bis jetzt wenig mit Mercurial gemacht, früher aber häufig darcs verwendet. Um Git richtig gut verwenden zu können, ist IMO ein bisschen mehr Wissen über Interna nötig, als bei Mercurial oder darcs. Die beiden (besonders darcs) skalieren besser nach unten. (Die staging area bei Git zB. ist ein tolles Feature, war anfangs aber etwas verwirrend.
Wie gesagt, ob Git oder Mercurial halte ich für Geschmackssache; beide sind verteilt, schnell, haben kompakte Repos, brauchbares Branching und sind so zuverlässig, dass man seinen Tools wirklich trauen kann. (Bei Subversion mit BDB ist es verdammt leicht, sich versehentlich ein Repo zu zerschießen, was mir mit Git und Mercurial noch nie passiert ist.)
-
RHBaum schrieb:
Unsere Anforderungen z.b.:
- Defizieles RechteManagmentDiffizil? Inwiefern?
(Ja, alles wo userspezifische Zugriffsrechte innerhalb eines Projekts für unterschiedliche Files unterschiedlich sein sollen, ist anstrengend. Meinst Du das?)
- Kommunikation ueber nur bestimmte protokolle fuer externe zugriffe. FTP/SFTP faellt raus wegen Sicherheitsapekte, direktzugriff (SSH, telnet ... ) faellt raus wegen Sicherheitsaspekte ... nfs/cifs(smb) no chance ... das einzige was geht ist http/https
SSH in Sachen Sicherheit mit telnet gleichzusetzen, finde ich schon hart.
SSH ist eine moderne Remote-Shell, die sich sehr gut für solche Aufgaben eignet. Ansonsten ist Schreibzugriff über HTTP in Git auch kein Problem.
Wenn ich bei einem so einen Project mal 3 Tage ned Comitte, bin ich hinterher locker schneller wenn ich meine Aenderungen verwerfe und in den aktuellen Stand komplett neu einpflege, als wie wenn ich die Kollisionen bearbeite ....
Aber doch nur deswegen, weil das Merging bei älteren Versionskontrollsystemen so mies ist. Ich höre oft "Branching ist doch ganz einfach" und das stimmt auch. Nur verwendet es niemand, weil das Merging so ein Riesenkrampf ist.
Moderne verteilte VCS haben für genau solche Einsatzzwecke richtig gutes Branching und Merging, das funktioniert wunderbar für solche Einsatzzwecke. Ist natürlich aber kein Ersatz dafür, hin und wieder miteinander zu reden.
-
Als weitere verteilte SVN-Alternative gibt es noch Bazaar
-
nman schrieb:
[...]
SolidOffline schrieb:
- git und mercurial sind besser weil: Beide System laufen lokal auf deinem Rechner und somit funktionieren beide auch dann, wenn du mal keine Internetverbindung hast. Wenn eine Verbindung besteht, kannst du die Änderungen mit dem Server abgleichen.
Aussage falsch, weil: SVN ebenfalls lokal läuft und ebenfalls auch dann bestens funktioniert, wenn keine Internetverbindung besteht.
- ... CVS und SVN beide einen Server benötigen, den Du irgendwo installieren musst, zB. bei Dir zuhause.
Aussage falsch, weil: SVN keinen Server benötigt, den man irgendwo installieren muss.
Die Aussagen sind nur dann falsch, wenn Du davon ausgehst, dass Du Dich a) beim Entwickeln immer auf einen Rechner beschränken kannst und b) immer alleine arbeitest.
Ich weiß nicht, wie häufig das bei Dir der Fall ist, aber bei mir kommt a) bei jedem Projekt irgendwann der Zeitpunkt, an dem ich gerne vom Laptop aus arbeiten möchte oder auf der Uni im Labor oä. und b) arbeite ich an der überwiegenden Mehrzahl meiner Projekte nicht alleine, weswegen Kollegen der Verweis auf den USB-Stick, auf dem mein Repo liegt, nicht viel hilft.
[...]
Da die Aussagen diese Einschränkung nicht machten und leider nunmal so allgemein gehalten waren, sind sie falsch. Du wirst mir sicher zustimmen, dass auch die Aussage "ein Ferrari ist langsam" falsch ist, wenn ich nicht schon in der Aussage die Einschränkung mache, dass ich einen von einem Moped abgeschleppten Ferrari meine.
Der Threadersteller sprach ausdrücklich von privater Nutzung. Ich denke da kann man einen Multi-User Betrieb (zumindest gleichzeitig) ausschließen. Dass auch ein Mehrrechnerbetrieb kein Problem ist, habe ich schon dargestellt -> zentrales Repository auf Stick, auf Netzlaufwerk oder ähnliches. Auch ein Multiuser-Betrieb (wenn nicht gleichzeitig) ist so ohne Probleme möglich.
An meinen privaten Projekten arbeite ich eigentlich immer alleine (wenn auch auf verschiedenen Rechnern mit verschiedenen Usern), maximal verwende ich einige Libraries auch auf arbeit, an denen ich privat fummle --> USB-Stick.
Aber eigentlich möchte ich gar nicht in die Ecke, in der die SVN-Verfechter sitzen.
Ich benutze SVN privat, weil es läuft und für mich völlig ausreicht, dass es bessere und modernere VCS gibt, habe ich nie bestritten. Ich habe bloß zwei Aussagen korrigiert bzw. der Korrektur zugestimmt, weil sie nunmal tatsächlich falsch waren.
Wenn ich noch kein VCS verwenden würde, würde ich wahrscheinlich ebenfalls git oder mercurial nehmen, sofern es für diese gute Addins für Visual Studio gibt. Das ändert aber immer noch nichts an der Tatsache, dass ich SVN für private Zwecke auch ohne extra Server, Internet oder wasauchimmer empfehlen kann, weil ich's halt auch so benutze.
Spricht ja nichts dagegen, dass Andere andere VCS empfehlen, nur dann bitte halt nicht aus den ersten zwei genannten falschen Gründen heraus, denn die Annahme, wenn jemand von privater Nutzung spricht, sollte eben nicht auf einen simultanen Multi-User Betrieb hinzielen.
Davon ab denke ich, dass der Troll (Threadersteller) nun satt sein dürfte.
-
SolidOffline schrieb:
Der Threadersteller sprach ausdrücklich von privater Nutzung.
Und offensichtlich hast Du andere Vorstellungen von "privater Nutzung" als ich. Meine privaten Projekte involvieren nämlich häufig andere Entwickler. Mit diesen anderen Entwicklern teile ich mir typischerweise keinen Zugang zu USB-Sticks, Samba-Shares oä., weil sie eben nicht eine Tür weiter sitzen.
(Mal ganz davon abgesehen dass sich private Projekte häufig recht fließend zu weniger privaten Projekten entwickeln.)
Deine "Ferrari ist langsam"-Analogie hinkt daher ein wenig. Nimm als Analogie lieber "Sind Ferraris alltagstauglich?". Ich würde darauf mit nein antworten, weil ich häufig in der Stadt Parkplätze suche und auf holprigen Landstraßen unterwegs bin, während Du das anders siehst, weil Du mit Deinem nur Autobahn fährst. Zugrunde liegt eben ein unterschiedliches Verständnis von alltagstauglich, nicht eine falsche Aussage.
-
Beide Aussagen sind für sich gesehen falsch, da sie die Einschränkungen/Annahmen, die sie zu wahren Aussagen machen würden nicht enthalten.
Aber ich stimme dir insofern zu, als dass die Annahme ein simultanter Multi-User Betrieb würde benötigt, implizit durch dein Verständnis von "privater Nutzung" vorgegeben war. Nach meinem Verständnis "privater Nutzung" waren die Aussagen dann natürlich falsch.
Sei noch angemerkt, dass ich mir mercurial wohl demnächst zumindest mal anschauen werde. Kann ich damit auch noch meine SVN-Projekte weiter verwalten und taugt das Visiual-Studio Addin (glaube hgSCC heißt es?) was?
-
PS: Heute morgen musste ich feststellen, dass ich meinen USB-Stick auf Arbeit vergessen habe. Hmmm...
-
Genau das ist ja der vorteil von den Verteilten Systemen.
Wenn man sein Stick vergessen hat geht es ja noch, da hängt alles halt nur eine gewisse Zeit.Aber was ist wenn man den Stick verliert, oder die Daten irreparabel beschädigt werden, oder versehentlich das Repo auf den Stick versehentlich gelöscht wurde.
Dann ist alles weg bis zum letzten Backup.
Bei den Verteilten System kann man immer Problemlos vom/zum Stick Pullen und Pushen, und wenn mit dem Stick was ist, einfach neu Pushen und fertig, alles wieder da
-
SolidOffline schrieb:
Kann ich damit auch noch meine SVN-Projekte weiter verwalten ...
Es gibt zumindest eine Erweiterung, welche dies erlauben soll. Ich habe damit allerdings keine Erfahrungen gemacht, nur davon gehört/gelesen, dass es sehr gut gehe:
hgsubversion
Integration mit TortoiseHgSolidOffline schrieb:
und taugt das Visiual-Studio Addin (glaube hgSCC heißt es?) was?
Es heisst HgSccPackage. Erfahrungen damit habe ich auch keine. Ich verbinde solche Dinge nicht gerne mit der IDE. Auch bei SVN habe ich das ganze immer extern gemacht. Ich verwalte schliesslich nicht nur Code und dazugehörige Ressourcen über ein VCS. Meistens kommen da noch verschiedene andere Dokumente, Scripts oder sonstige Files dazu, von welchen meine IDE nichts weiss.
Grüssli
-
Ok, danke, ich werd's mir bei Gelegenheit mal ansehen. Eine schöne IDE-Integration ist bei mir ein Muss und Zucker wäre natürlich, wenn ich meine SVN-Projekte dann auch noch weiter verwalten könnte.
Schaumermal.
-
CSL schrieb:
Stimmt schon, nur Git hat ein Automatisches "Backup".
Jeder der aus checkt hat es, wenn deine Platte ab raucht, frag jemanden der es noch aus gecheckt hat ob er dir sein Repo geben kann, schon ist alles wieder da.Das ist quatsch. Hört auf so einen gefährlichen unsinn zu verbreiten. Ein verteiltes system kann ein backup NICHT ersetzen. Denn das würde voraussetzen, dass es immer jemanden gibt die den aktuellsten stand hat. Und das ist nicht garantiert. Denn wenn deine platte abraucht, nachdem sich das letzte mal vor 3 wochen jemand eine kopie gezogen hat, dann ist alle arbeit der letzten 3 wochen im eimer. Man sollte auf dem boden der tatsachen bleiben, wenn man sein system übern klee lobt.
Ein punkt würde mich bei git mal interessieren:
Kann ich bei git eine lesbare brauchbare revision bekommen? Also etwas was man auch kunden per telefon durchgeben lassen kann ("version 36182")? Oder geht nix ausser diesen hashes, wahrscheinlich konzeptbedingt? Auch ein punkt, der durchaus gegen so ein system sprechen kann.
-
KuhTee schrieb:
Ein punkt würde mich bei git mal interessieren:
Kann ich bei git eine lesbare brauchbare revision bekommen? Also etwas was man auch kunden per telefon durchgeben lassen kann ("version 36182")? Oder geht nix ausser diesen hashes, wahrscheinlich konzeptbedingt? Auch ein punkt, der durchaus gegen so ein system sprechen kann.Klar geht das: Die ersten 7 Zeichen eines Hashs identifizieren den commit fast immer eindeutig.
Anzeigen lassen kannst du dir diese kurzen Revisionsnummern mit:
git log --abbrev-commitAndererseits würde man Kunden wahrscheinlich sowieso keine Revision durchgeben, sondern viel eher ein Tag. Tagging geht in git sehr schnell und speichersparend.
-
An so einen "abgeschnittenen" hash hatte ich auch schon gedacht. Das "fast immer" ist nur so eine wankelige phrase...
Das mit dem tag stimmt schon. Bei einer sehr modularen software ist das aber auch nicht immer gewährleistet. Es gibt durchaus schon situationen wo man einfach eine revision braucht, nicht nur den tag des ganzen pakets.
Tags verwende ich in SVN auch so zur genüge (wie auch branches).
-
KuhTee schrieb:
CSL schrieb:
Stimmt schon, nur Git hat ein Automatisches "Backup".
Jeder der aus checkt hat es, wenn deine Platte ab raucht, frag jemanden der es noch aus gecheckt hat ob er dir sein Repo geben kann, schon ist alles wieder da.Das ist quatsch. Hört auf so einen gefährlichen unsinn zu verbreiten.
Nein, eigentlich nicht. Ich würde es nicht als automatisches Backup bezeichnen, aber auch CSL hat das unter Anführungszeichen gesetzt. Und von wegen voraussetzen, dass irgendwer die aktuellste Version gezogen hat: Die aktuellste Version hast Du typischerweise nach dem Push auf den Server mindestens zweimal: Auf Deinem Arbeitsrechner und am Server. Insofern tatsächlich kein Problem, wenn Dir dort was gröberes abraucht. Such einfach mal, bei Berlios kam sowas mal vor, damals hieß es "Git- und Mercurial-Benutzer machen bitte ein Push, Subversion-Entwicklern müssen wir leider mitteilen, dass wir die Commits der letzten n Wochen verloren haben".
Klar, wenn Du davon ausgehst, dass der Workflow so ist, dass sich irgendjemand Zeugs direkt von meinem Laptop pullt, dann ist das natürlich Blödsinn. Aber so arbeitet man auch mit einem verteilten VCS nicht - selbst wenn das theoretisch ginge und in manchen Situationen nicht unpraktisch ist. (Zb. bei Forentreffen mitten in der Pampa und ohne Server- oder Internetzugang. :))
An so einen "abgeschnittenen" hash hatte ich auch schon gedacht. Das "fast immer" ist nur so eine wankelige phrase...
Naja, klingt natürlich böse. Aber weißt Du ungefähr, wie SHA21 funktioniert? Das "fast" bedeutet an dieser Stelle nicht "Ich habe damit in der Praxis nur manchmal Schwierigkeiten", das ist eben ein kryptografisches "fast".
Das mit dem tag stimmt schon. Bei einer sehr modularen software ist das aber auch nicht immer gewährleistet. Es gibt durchaus schon situationen wo man einfach eine revision braucht, nicht nur den tag des ganzen pakets.
Zum Beispiel? Der Tag ist ja nichts anderes als ein hübscherer Name für den langen SHA-Hash. Warum soll der SHA besser sein als ein Tag?
-
Sooo, nach einer Weile melde ich mich nun mal wieder mit einem Erfahrungsbericht...
Nachdem ich Mercurial, also ein DVCS inklusive Visual Studio Addin (hgscc) eine Weile ausprobiert habe, bin ich doch wieder reumütig zu meiner Subversion-auf-Stick Lösung zurückgekehrt (Konvertierung der einzelnen Projekte im SVN-Repository nach Mercurial funktionierte übrigens problemlos über die hg.exe von TortoiseHg). Vorab nochmal zur Erinnerung: ich arbeite alleine an meinen Projekten, wenn auch von unterschiedlichen Rechnern, mit unterschiedlichen Usern, jedoch nie mit mehreren Usern gleichzeitig. Hier die Gründe im einzelnen:
Konfiguration von Mercurial: ein zentrales Repository auf Stick, alle anderen Repositories entsprechend lokal auf den Rechnern verteilt.
1.) Das Addin ist nicht soooo prickelnd. Besonders folgende Nachteile gegenüber Ankh fielen negativ auf:
- Wenn mehrere andere Projekte zusätzlich zum Hauptprojekt in einer Solution zusammengefasst sind, muss jedes einzelne Sub-Projekt für sich angeklickt werden um zu committen. Ankh zeigt alles in einem "Pending Changes" Fenster und man sieht sofort auf einen Blick, was sich in welchen Projekten der Solution geändert hat.
- Die Integration in die IDE besteht eigentlich nur aus einer Symbolleiste. Sämtliche von dort aus aufgerufenen Funktionen geschehen in eigenen, nicht andockbaren Fenstern (z.B. Diff). Ankh integriert seine Fenster (z.B. Diff) in die IDE, und ich kann die andocken wo ich will.
- Bei Ankh genügt ein "Update" der Solution und das Hauptprojekt + alle eingebundenen Unterprojekte (z.B. Klassenbibliotheken etc.) werden upgedated. Bei hgscc müsste ich die Solution + alle Unterprojekte einzeln anklicken und dort ein "pull" aufrufen.
2.) Die Handhabung ist für meine Zwecke einfach nicht so praktikabel und bringt mir aus meiner Sicht keine Vorteile:
- Zusätzlich zum committen muss ich mir auch noch merken, in welchen Projekten ich denn nun Änderungen committed habe und die dann auch noch einzeln auf das Repository auf dem Stick pushen.
- Beim Wechsel zu einem anderen Rechner muss ich erstmal alle Subprojekt-Repositories vom Stick pullen, denn ich merke mir ja nicht, wo ich nun auf dem anderen Rechner irgendwann mal was geändert habe. Zur Erinnerung: bei SVN und Ankh genügt ein Klick auf "Update" in der Solution.
- Ich habe keinen Vorteil durch die verteilten Repositories, denn ich muss trotzdem immer das zentrale (Stick) dabeihaben. Warum? Na, wenn ich auf Arbeit an einer Solution gearbeitet habe (Hauptprojekt und evtl. auch Änderungen in Unterprojekten), dann hätte ich diese Änderungen schon auch gerne zuhause zum weiterarbeiten.
Nun kann man zu manchen Punkten sicherlich antworten: "da schreibst dir halt ein Skript, das das automatisch macht (z.B. pullen aller Projekte vom Stick)", aber ganz ehrlich: warum sollte ich mir die Arbeit machen, wenn ich mit SVN + Anhk dasselbe in grün nur viel komfortabler habe?
Also alles in Allem: Test war erfolgreich, Ergebnis: ich bleibe bei SVN.
Vorteil des Ganzen: habe nun auch Mercurial + Visual Studio Addin installiert (beißt sich nicht mit Ankh) und bin für alle Fälle gewapnet.
-
Ich habe keinen Vorteil durch die verteilten Repositories, denn ich muss trotzdem immer das zentrale (Stick) dabeihaben.
Irgendwie hast du das Prinzip wohl noch nicht verstanden. Jedenfalls muß man diesen Stick nicht jeden Tag dabei haben.
-
Tyrdal schrieb:
Ich habe keinen Vorteil durch die verteilten Repositories, denn ich muss trotzdem immer das zentrale (Stick) dabeihaben.
Irgendwie hast du das Prinzip wohl noch nicht verstanden. Jedenfalls muß man diesen Stick nicht jeden Tag dabei haben.
Ach, und wie glaubst du, sollen die geänderten Projektdateien von meiner Arbeit zu mir nach Hause (bzw. vom mir zuhause zur Arbeit) kommen, damit ich an diesen weiterarbeiten kann? Telepathie? Jedesmal komplett die Repos clonen? Wohin clonen? Auf die telepathische Schnittstelle?
Vorteil eines DVCS hätte ich dann, wenn ich zuhause generell nur an anderen Projekten oder an anderen Teilen innerhalb eines Projekts arbeiten würde, als auf Arbeit - und selbst dann kann es passieren, dass auch mal Unterprojekte referenziert werden, die auf Arbeit geändert wurden. Aber meißt ist es nunmal so, dass ich zum weiterarbeiten die Änderungen, die am anderen Ort gemacht wurden brauche. Ergo muss ich Änderungen pullen, ergo brauche ich zusätzlich ein zentrales Repo.
Bitte solche Zwei-Sekunden-nachgedacht-Einzeiler in Zukunft vermeiden. Danke.
-
Ich weiß schon was ich schreibe.
Das Problem war doch, daß deinen Stick vergessen hattest. Mit DVCS kann st du trotzdem weiterarbeiten und halt irgendwann später mit dem Stick synchronisieren. Mit Subversion haste dann halt Pech.
-
Tyrdal schrieb:
Ich weiß schon was ich schreibe.
Das Problem war doch, daß deinen Stick vergessen hattest. Mit DVCS kannst du trotzdem weiterarbeiten und halt irgendwann später mit dem Stick synchronisieren. Mit Subversion haste dann halt Pech.
Ich bitte dich.
Im vorigen Beitrag habe ich eigentlich schon alles erwähnt, was man benötigt, um mit ein wenig Nachdenken darauf zu kommen, dass mir ein DVCS in dem Fall auch nicht weitergeholfen hätte.
Aber hier nochmal: ich wollte zuhause an einem Projekt weiterarbeiten... dazu benötigte ich zuhause auch die Änderungen, die auf Arbeit an dem Projekt gemacht wurden. Ich hätte also auch mit einem DVCS irgendwie meinen Projektstand zuhause erstmal aktualisieren müssen.
Manchmal hängen Module halt vom Vorhandensein oder einer bestimmten Funktionsweise anderer Module ab. Wurden auf Arbeit sowohl Modul B, das von Modul A abhängt, als auch Modul A geändert, so wäre es ganz sinnvoll zuhause das geänderte Modul A und auch das geänderte Modul B zur Verfügung zu haben, um vernüftig weiterarbeiten (und testen) zu können. Kommt auch oft vor, dass ich eine Klasse auf Arbeit halb fertig habe und diese dann zuhause komplettiere. Wie soll das mit einem DVCS ohne zentrales Repository funktionieren, wenn das lokale Repo zuhause die Klasse noch nichtmal kennt? Kurz die Klasse aus dem Kopf soweit neu schreiben?