Seit kurzem gibt es auf Mikrocontroller.net einen SVN-Server. Wer es nicht kennt: SVN (Subversion) ist ein Versionsverwaltungssystem, in dem Sourcecode und sonstige Dateien (z.B. Schaltpläne und Layouts) an einer zentralen Stelle verwaltet werden. Jede Änderung kann kommentiert werden und sämtliche alten Versionen werden archiviert. Dadurch lässt sich einfach der Verlauf der Entwicklung mitverfolgen, was besonders bei Projekten an denen mehrere Entwickler arbeiten nützlich ist. Der SVN-Server steht allen Benutzern zur Verfügung die ein Open-Source-Projekt starten möchten, egal ob es ein größeres Projekt mit Hard- und Software oder nur eine kleine Bibliothek mit ein paar Funktionen ist. Wer Interesse hat, der kann sich "per E-Mail":mailto:webmaster@mikrocontroller.net melden um sich das Projekt auf dem Server einrichten zu lassen. Der Zugriff für weitere Benutzer lässt sich dann selbst über ein Webinterface konfigurieren. Mehr Informationen gibt es im Wiki unter "Hilfe: SVN":http://www.mikrocontroller.net/articles/Hilfe:SVN. Eine Liste der aktuell auf dem SVN-Server gehosteten Projekte gibt es "hier":http://www.mikrocontroller.net/svn/list.
:
Verschoben durch Admin
wow, cool, vielen Dank schonmal - werde bei Bedarf drauf zurückgreifen!
Mikrocontroller.net ist eine super Seite, aber in Zeiten von verteilten Versionskontrollsystemen noch ein Subversion-Repository aufzusetzen solltet ihr nochmal überdenken. Liebe Grüße MiT0
ich findes es wirklich super dass ihr solcen service anbietet, aber warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll ja schliesslich mit der zeit gehn... ;) trotzdem vielen dank fuer den service! das wird bestimmt anklang finden.
zachso schrieb: > ich findes es wirklich super dass ihr solcen service anbietet, aber > warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll > ja schliesslich mit der zeit gehn... ;) trotzdem vielen dank fuer den > service! das wird bestimmt anklang finden. Ich kann mich dem nur anschliessen - ein Versionskontrollsystem ist sicher eine Hilfe bei der Suche nach der aktuellen Version und Studium der Geschichte von Code. Aber SVN macht mich schreiend davonlaufen, insbesonders wenns um kompliziertere Merges geht. Könntet Ihr das nochmal überdenken? Git + Gitweb wärs gewesen. Jetzt sind erst drei Projekte drin. Die Migration SVN->Git ist auch ziemlich easy. liebe Grüsse, Michael ps: Linus Torvalds zum Thema: http://www.youtube.com/watch?v=4XpnKHJAok8
zachso schrieb: > das waere ein wenig zeitgemaeser gewesen, git ist anders, aber warum sollte es zeitgemäßer sein? Ich persönlich kann mich damit gar nicht anfreunden, weil ich darin immer die latente Gefahr sehe, dass jeder sein Süppchen kocht und alles prima auseinander läuft. Ob git für die hier in Frage kommenden Projekte eventuell besser geeignet wäre als SVN, will ich damit nicht in Abrede stellen (dafür habe ich zu wenig Gefühl für diese Projekte). Ich bestreite lediglich den Ausdruck "zeitgemäßer", nur weil sich vielleich dieses oder jenes prominente Opensource-Projekt nach jahrzehntelanger Abstinenz von jeglicher Versionsverwaltung mal dafür entschieden hat. Wenn's unbedingt verteilt sein soll, käme außerdem noch Mercurial mit ins Spiel.
RTFM: http://www.mikrocontroller.net/articles/Hilfe:SVN -> "Warum SVN?" ;) SVN ist am weitesten verbreitet, wird in vielen Firmen verwendet und ist auch unter Windows gut benutzbar. Bei den verteilten Systemen gibt es git, Mercurial, Bazaar, darcs, und jeder will was anderes verwenden. Und mal ehrlich, wie kompliziert werden die merges bei den Projekten um die es hier geht? Das sind keine Linux-Kernel mit tausenden von Dateien und dutzenden Branches, das sind Projekte mit ein paar C-Dateien, einem Boardlayout oder zwei, und das war's. Da ist git u.ä. völliger Overkill, und macht das ganze nur undurchsichtiger, besonders für Benutzer die wenig Erfahrung mit Versionskontrollsystemen haben. Wenn sich herausstellen sollte dass sich immer mehr Leute für git interessieren, und es auch wirklich Gründe gibt das zu nutzen, dann kann man da in Zukunft sicher eine Lösung finden. Im Moment halte ich SVN aber für die beste Lösung.
> ich findes es wirklich super dass ihr solcen service anbietet, aber > warum kein git? das waere ein wenig zeitgemaeser gewesen, und man soll > ja schliesslich mit der zeit gehn... ;) ??? SVN ist der nachfolger von CVS. Es wird u.a. auch auf Windows sehr gut unterstützt (Tortoise). Und für solche Projekte find ich SVN besser. Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer, jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind Programmmierer teilweise ein sehr eigenbrötlerisches Volk.
Andreas Schwarz schrieb: > Und mal ehrlich, wie kompliziert werden die merges bei den Projekten um > die es hier geht? Genau das ist der Punkt. Es geht hier um eine möglichst einfach zu bedienende Zugriffsmöglichkeit auf die jeweils aktuelle Version. Sonst nichts. Und dafür ist svn das Mittel der Wahl. > Da ist git u.ä. völliger Overkill, Overkill? Das glaube ich nun weniger. Git ist für den angepeilten Zweck wenig geeignet, weil es gerade kein zentrale Repositorium hat - dessen Funktion wird mit Hilfe von Schreibrechten auf öffentlich zugängliche Repositorien simuliert, was aber impliziert, daß diese Repositorien administriert werden müssen, man also sowas wie Projektleiter braucht. > und macht das ganze nur undurchsichtiger, besonders für Benutzer die > wenig Erfahrung mit Versionskontrollsystemen haben. Nein es würde nur die bisher benutze, unbefiedigende Methode - bei der man sich die neuste Version aus irgendwelchen Threads rauspulen mußte - "modernisieren", ohne wirklich was daran zu ändern. Gemerged wurde hier bisher so gut wie überhaupt nicht und wenn ich es richtig sehe, hat sich daran auch so gut wie keiner gestört. byte schrieb: > Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer, > jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind > Programmmierer teilweise ein sehr eigenbrötlerisches Volk. Genau, ohne Projektleitung kann das nicht funktionieren. Also liebe Modernisierer, nicht alles Neue ist gut, nur weil es neu ist...
Vielen Dank, Super Service! Zum Gl"uck gab es nicht nur Stimmen f"ur git und gegen Subversion, wie es in den ersten paar Beitr"agen den Anschein hatte. Mit geht's fast schon auf den Hammer, wie die Leute hinter einem Linus T. herlaufen ohne nachzudenken. Wer svn und git benutzt wird merken, dass bei git nicht alles besser ist. Das Modell ist sogar noch komplizierter. Wozu? Als ich mir git genauer anschaute und f"ur meine mittlerweile recht umfangreiche Bibliothek benutzen wollte musste ich feststellen, dass es keine Entsprechung zu den 'externals' von Subversion gab. Ich benutze als single user die Versionskontrolle um mehrere Architekturen (i386,SAM7s,LPC21,LPC23 und LPC17) zu unterst"utzen und maximal viel Code gemeinsam nutzen zu k"onnen. Dazu muss ich den Code in viele Klassen einteilen wie: C freestanding/C linux/C++/C-LPC21/C-LPC23/... Da finde ich die externals ein brilliantes Werkzeug und das vor allem seit Version 1.6 . Da hat git was nachzuholen! Gruss Marc
Dieses " macht deinen Text aber nicht besonders viel lesbarer :O
Simon K. schrieb:
> Dieses " macht deinen Text aber nicht besonders viel lesbarer :O
Vielleicht kann ja sein PDA oder Navi nicht anders... ;-)
...
Hannes Lux schrieb:
> Vielleicht kann ja sein PDA oder Navi nicht anders... ;-)
...oder er hat eine englische Tastatur. Ist bei manchen old-time-
Hackern recht beliebt. Das vorangestellte Anführungszeichen ist die
LaTeX-Abkürzung für die Umlaute (braucht man bei LaTeX aber auch
schon 10 Jahre lang nicht mehr).
Marc Prager schrieb: > Als ich mir git genauer anschaute und für meine mittlerweile recht > umfangreiche Bibliothek benutzen wollte musste ich feststellen, dass es > keine Entsprechung zu den 'externals' von Subversion gab. Ich bin nicht 100%ig sicher, ob es eine genaue Entsprechung ist, aber es gibt in git das Konzept von "submodules", das mir sehr ähnlich erscheint. An dieser Stelle schließe ich mich auch nochmal den Git-Fans an, wer einmal mit einer großen Sourcecodebasis und git gearbeitet hat, weiß es zu schätzen, dass git einfach rattenschnell ist, auch bei komplexen Operationen. Das bewusste einkalkulieren, dass Entwicklung nicht unbedingt immer linear stattfindet macht git manchmal etwas schwer zugänglich, ist aber häufig eine große Hilfe. Klar, solange es nur um Mini-Projekte geht merkt man das nicht unbedingt, aber bei größeren Sachen wundert man sich schon manchmal wie einfach mit Git manchmal Dinge gehen, die mit SVN immer wieder gerne mal aufgeschoben werden, weil sie so lästig sind... Viele Grüße, Simon
> SVN ist am weitesten verbreitet, wird in vielen Firmen verwendet und ist > auch unter Windows gut benutzbar Sollen das pro oder contra-punkte sein? > Bei den anderen (Git, Mercurial, etc.) Murxen immer alle kreuz und quer, > jeder stickt sein eigenes Zeug, und keiner gibts weiter. Leider sind > Programmmierer teilweise ein sehr eigenbrötlerisches Volk. Dafür machen es die verteilten systeme auch einfacher branches wieder zusammenzuführen. > Mit geht's fast > schon auf den Hammer, wie die Leute hinter einem Linus T. herlaufen ohne > nachzudenken Ist halt wie damals mit Bill G. und nun mit Steve J. ... Wie Andreas schon schrieb ist git wohl eher overkill von daher wär evtl. Tatsächlich Mercurial, wegen seiner geringeren komplexität, eine alternative. @Andreas: trotzdem eine schöne Sache =) @Rechtschreib/GramatikNazis: geht wo anders spielen
Tire D. schrieb: > Dafür machen es die verteilten systeme auch einfacher branches wieder > zusammenzuführen. ...die man allerdings in kleineren Projekten eher selten benötigt.
Jörg Wunsch schrieb: > Tire D. schrieb: >> Dafür machen es die verteilten systeme auch einfacher branches wieder >> zusammenzuführen. > > ...die man allerdings in kleineren Projekten eher selten benötigt. Naja vielleicht ergibt sich ja aber eine neue kultur was die Projekte angeht. Ich meine es ist mit dezentralen Systemen schmerzfreier 'mal ebend was zu machen' und dieses evtl. danach in den Trunk einzuführen, wodurch die hemmschwelle fallen könnte an dem Projekt teilzuhaben. (Denke dadurch entsteht auch dieser besagte Wildwuchs, aber auch ein blindes Huhn findet mal ein Korn;)) Grad Mercurial ist ja recht simpel mit seinem einen komando + ein paar optionen, wohingegen git da ja genau den anderen ansatz fährt. Aber (ka obs wirklich so ist) ich denke da gibts für beide (wenn nicht jetzt schon, so doch in absehbarer Zukunft) schicke frontends die einem das ganze recht einfach gestalten. Von daher frag ich mich wo der Vorteil von SVN liegt. scnr Aber wahrscheinlich ist das alles auch nur Wunschdenken :)
Gibt es hier irgendwo eine Beschreibung wie man genau an die Projekte rankommt. Ich bekomme hier nur kryptische Fehlermeldungen
Andreas Schwarz schrieb: > Mehr Informationen gibt es im Wiki unter "Hilfe: > SVN":http://www.mikrocontroller.net/articles/Hilfe:SVN. Eine Liste der > aktuell auf dem SVN-Server gehosteten Projekte gibt es > "hier":http://www.mikrocontroller.net/svn/list. http://www.google.de/search?hl=de&q=subversion
Sehr witzig, da steht doch überhaupt nix. "Sie sind nicht dazu berechtigt diese Seite aufzurufen." Wenn ich versuche z.B. auf svn://mikrocontroller.net/test zuzugreifen kommt die Meldung: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte. Frage also: Gibt es irgendwo eine einfach Anleitung wie man sich mit dem Repository verbindet, oder ist das auch so ein krytisches Linuxzeug MfG
joachim7777 schrieb: > Wenn ich versuche z.B. auf svn://mikrocontroller.net/test zuzugreifen naja, ich kann zugreifen. Wie probierst du es denn? Mit dem Browser? Unter Linux geht es einfach, in der Konsole konnte ich eben mit:
1 | svn co svn://mikrocontroller.net/avr-fat32 |
testweise ein Projekt holen (svn co... zum Aus{}checken, den Rest
aus der Liste http://www.mikrocontroller.net/svn/list).
Wenn das zu kryptisch ist: was ist einfacher?
joachim7777 schrieb:
> Sehr witzig, da steht doch überhaupt nix.
> "Sie sind nicht dazu berechtigt diese Seite aufzurufen."
Sowohl auf den Link http://www.mikrocontroller.net/articles/Hilfe:SVN
als auch http://www.mikrocontroller.net/svn/list
kann ich problemlos zugreifen.
Ich versuche es mit dem Windows-Explorer, rechte Maustaste -> TortoiseSVN->Checkout Wenn ich die Repository-URL svn://.... eingebe kommt die vorher genannte Meldung wenn ich die http-Url angebe kommt die Meldung OPTIONS of 'http://www.mikrocontroller.net/svn/list';: 200 OK es wird aber nix geladen. Linux habe ich leider zuhause nicht, mir reicht es wenn ich mich mit dem Mist in der Firma beschäftigen muss.
Ich habe jetzt mal auf einem Reserve-Windows Tortoise installiert (nachdem ich sonst nur den Mist nehme). Dann gehe ich im Explorer auf Check out...., bis dahin scheint es ja bei dir zu klappen. Als URL gebe ich ein:
1 | svn://wwww.mikrocontroller.net/rfm12 |
oder ein anderes Projekt aus der Liste. Ggf. den lokalen Pfad anpassen, und es wird geholt und lokal gespeichert. Soweit klappt das bei mir. Wo weicht es genau ab bei dir? (Dagegen kannst du bei checkout nicht: http://www.mikrocontroller.net/svn/list angeben, weil das eine http-URL ist. Da kann man mit dem Browser hingehen, z.B. Mozilla, firefox oder IE. Da bekommt man die Liste der Projekte.)
Nachtrag: 1. In meinem obigen Beispiel ist ein w zuviel; es müsste heißen: Als URL gebe ich ein:
1 | svn://www.mikrocontroller.net/rfm12 |
... 2. Ich habe mal spaßeshalber die obige URL (mit nur 3 w :-) im Firefox eingegeben (Version 3.6, unter Windows XP). Dann bietet er mir gleich Tortoise an als Anwendung, darüber kann man auch die Dateien holen (man hat in dem folgenden Dialog mit der Baumansicht des Projekts mit der rechten Maustaste wieder ein Menü mit "Check out.." drin).
also ich hab die ganzen Beiträge sehr interessiert gelesen und frag mich nur was die ganzen Diskussion soll? (git <-> svn; und dann wieder linux <-> windows) Ich nutze 4 verschiedene Rechner an 4 verscheidenen Orten mit insgesamt 3 verschiedenen Betriebssystemen mit all ihren Vor- und Nachteilen. Mich würde jetzt nur interessieren, da ich mich mit svn nun mal garnicht auskenne, ob ich dann meine hochgeladenen Projekte "passwortschützen" kann und von überall dran arbeiten kann? Damit wäre mir schon sehr geholfen und ich hätte dann die komplette Entwicklung eines Projektes auf einem Fleck und müsste nicht nachträglich alles zusammensuchen bzw. immer alles per Mail/USB hin und her schieben.
ja, kannst du. Ob der svn-Server bei mikrocontroller.net jetzt dafür gedacht ist, daß du selbst deine Projekte als einziger bearbeitest, glaube ich mal nicht. Aber ansonsten geht das prima mit svn. Ich habe ziemlich alles, was für mich auf irgendeinem Rechner irgendwie relevant ist (Quelltexte, Briefe, Steuererklärungen, Doku, Adressen, Termine...) inzwischen in svn und kann an jedem Rechner auf die gleichen Daten zugreifen, gelegentliches Einchecken und Updaten vorausgesetzt natürlich. Als svn-Server habe ich einen PC zuhause, der über dyndns und ssh von außen erreichbar ist, d.h. ich kann notfalls vom Laptop aus über irgendeinen Internetzugang auf alles zugreifen. (Das ist aber kaum nötig, weil ich ja vor dem Weggehen i.d.R. auf dem Laptop ein svn update mache und dadurch mit dem aktuellen Stand losziehe, daheim ändert bei mir niemand etwas.) Mit ssh auf einem Linuxserver halte ich das für hinreichend sicher. PS: ich nutze als Clients Linux und Windows, unter Windows zusammen mit putty wg. der Verschlüsselung über ssh. Das klappt auch gut.
Nachtrag: ich schütze i.d.R. nicht die Projekte selbst mit einem PW oder ähnlichem, sondern die gesamte Verschlüsselung findet über ssh statt. ssh dient primär dazu, von einem Rechner auf einen anderen zu gelangen und dort Kommandos auszuführen, ähnlich wie beim guten alten telnet, nur halt die Übertragung verschlüsselt und komprimiert. Um jetzt nur auf einem lokalen Rechner sowohl den svn-Server zu betreiben und auch dort als Client auszuchecken, würde man das svn-eigene Protokoll svn angeben und verwenden, also z.B. holen mit dem Kommando:
1 | svn co svn://svn/meintollesprojekt |
, falls man das Projekt als svn/meintollesprojekt angelegt hatte. Mit GUI-Spielen wie tortoise etc. halt entsprechend. Läuft auf dem Server gleichzeitig ein ssh-Server, dann kann man darauf einfach über das Netz zugreifen mit dem Protokoll svn+ssh. Das würde dann irgendwo im Internet so aussehen:
1 | svn co svn+ssh://meinbenutzername@meinrechner.dyndns.org/svn/meintollesprojekt |
Was ich damit sagen will: nicht svn wird das verschlüsseln, sondern es wird letztlich eine ssh-Verbindung für einen bestimmten Nutzer aufgebaut, und darin findet die Verschlüsselung statt. Die meisten Sachen, die ich im svn habe, gehören demnach einfach zu meinem Benutzernamen. Gelegentlich kommt es vor, daß ich externe Leute auf einzelne Teile zugreifen lassen möchte. Dann richte ich für die einen neuen Benutzer ein (unabhängig von svn, einfach als Benutzer auf dem Server), packe diesen in eine eigene Gruppe und nehme mich selbst in diese Gruppe dazu. Normale Benutzerberechtigungen in Unix halt. Das Projekt im svn gehört dann diesem neuen Benutzer, der kann dann auch einfach außen genau auf dieses Projekt zugreifen und ich natürlich auch, weil ich in der Gruppe bin. Er kommt dagegen nicht an meine Sachen ran. --- Hauptvorteil neben dem schönen Abgleichen aller Daten ist für mich, daß ich genau eine Stelle habe, an der ich Datensicherung machen muß. Das ist nämlich genau das svn-Repository. Auf allen Rechner ist nichts wichtiges drauf, was nicht auch im svn-Repository steht. Ich mache also regelmäßiges Backup nur auf einem Rechner. Allerdings sollte man nicht das Repository direkt als Dateien sichern, sondern einen Dump machen, und diesen sichern. Sonst läuft man Gefahr, daß der Server irgendwann stirbt und die Sicherung nur genutzt werden könnte, wieder einen svn-Server DERSELBEN Version wie der alte damit füttern zu können. Bei einem Dump im Backup dagegen kann man davon ausgehen, daß es auch eine neuere svn-Version einspielen kann.
Nur zur Info: Es gibt auch TortoiseGit und Mercurial! Meiner Erfahrung in der Firma ist, dass SVN zu kompliziert für embedded Programmierer ist! Sobald man wegbranched kennt sich keiner mehr aus. Bei git/mercurial einfach Repo-Dir kopieren (oder clonen... je nach Geschmack) und passt. Vorallem kann man lokal das machen, ohne dass es im Repo aufscheint (z.B um schnell mal eine dumme idee auszuprobieren) IDE Integration in Netbeans/Eclipse (sorry aber Keil/IAR sind keine IDEs, sonder maximal mit PN2 zu vergleichen) is brauchbar, also würde ich zumindest Git/Mercurial/Bazar einmal RICHTIG ausprobieren bevor ich von angeblicher komplexität spreche. Typischer Workflow von Mercurial/GIT: Repo anfordern Repo auschecken ändern (vielleicht lokale commits um Änderungen verfolgen zu können) hochladen (push) änderungen herunter holen (pull) repo auf neuen stand bringen (update/merge so ähnlich wie in svn) ändern push das wars eigentlich! Übrigends ich arbeite jetzt in der Firma lokal mit gitSVN. Damit arbeite ich lokal mit allen vorteilen von git und veröffentliche auf einem SVN ohne dummes reintegrieren von dem man spätestens beim mergen hirnödeme bekommt ;) privat habe ich einen Mercurial server auf einem shared webspace laufen... geht wunderbar weil sich mercurial über cgi benutzen lässt (bei git habe ich mir das noch nicht angeschaut). Auch ganz nett ;)
Hans schrieb: > Nur zur Info: Es gibt auch TortoiseGit und Mercurial! > > Meiner Erfahrung in der Firma ist, dass SVN zu kompliziert für embedded > Programmierer ist! > > Sobald man wegbranched kennt sich keiner mehr aus. Bei git/mercurial > einfach Repo-Dir kopieren (oder clonen... je nach Geschmack) und passt. > Vorallem kann man lokal das machen, ohne dass es im Repo aufscheint (z.B > um schnell mal eine dumme idee auszuprobieren) > Bei SVN ist das nicht anders.
Ich meinte lokal ausprobieren, aber versioniert.... http://whygitisbetterthanx.com/#svn naja ist schon zu offtopic -> klinke mich aus... ich kann auf jeden fall jedem empfehlen git/mercurial einmal auszuprobieren...
Hans schrieb: > Ich meinte lokal ausprobieren, aber versioniert.... Was sich dafür auch gut macht ist, mal schnell ein Mercurial-Repo über eine SVN-Arbeitskopie zu legen. Da kann man dann lokal versionieren, und entweder wirft man's hinterher wieder weg, oder man spielt irgendwann das Ergebnis komplett upstream ins SVN zurück.
Jörg Wunsch schrieb: > Was sich dafür auch gut macht ist, mal schnell ein Mercurial-Repo > über eine SVN-Arbeitskopie zu legen. Oder eben wahlweise gleich git zu nehmen. Das kann auch mit dem zentralen svn-Repo umgehen und das Ergebnis der lokalen Arbeit dort einchecken.
Johannes S. schrieb: > Das kann auch mit dem > zentralen svn-Repo umgehen und das Ergebnis der lokalen Arbeit dort > einchecken. Warum sollte man das wollen? Wenn ich es auf den Server zurück schreiben will, kann ich doch allemal den svn-Befehl nehmen. Der Vorteil des lokalen Overlays ist ja gerade, dass man eine (temporäre) Versionierung hat (und damit die Möglichkeit, bestimmte Zwischenschritte zu sichern), ohne alles auf den Server rüberschieben zu müssen. Finde ich manchmal praktischer als eine reine Mercurial-Umgebung, bei der jeder meiner Mini-Commits dann hinterher dauerhaft im Repo ist. (Könnte man vermutlich auch mit einem lokalen Branch lösen, ist aber auch nur Arbeit. Ein hg init … lokales Arbeiten … svn commit; rm -rf .hg ist einfacher.) Was ich an git absolut nicht leiden kann ist der Evangelismus, der damit zuweilen betrieben wird …
Jörg Wunsch schrieb: > Warum sollte man das wollen? Wenn ich es auf den Server zurück > schreiben will, kann ich doch allemal den svn-Befehl nehmen. Du brauchst svn überhaupt nicht dafür, deswegen "sollte man das wollen". Man muss sich nicht mit beiden Systemen auseinandersetzen. > Der Vorteil des lokalen Overlays ist ja gerade, dass man eine > (temporäre) Versionierung hat (und damit die Möglichkeit, bestimmte > Zwischenschritte zu sichern), ohne alles auf den Server > rüberschieben zu müssen. Genau das tut man ja mit git lokal. Man hat gern auch mehrere Branches, entwickelt gleichzeitig an 17 Varianten herum, committed "early and often" (so wie man das ja auch tun soll) und schiebt aller Naselang nur die Ergebnisse seiner Arbeit ins zentrale svn. Nach einer Weile wird das zentrale svn dann von einem zentralen git abgelöst, vertrau mir. :-P > Finde ich manchmal praktischer als eine > reine Mercurial-Umgebung, bei der jeder meiner Mini-Commits dann > hinterher dauerhaft im Repo ist. (Könnte man vermutlich auch mit > einem lokalen Branch lösen, ist aber auch nur Arbeit. Ein hg init > … lokales Arbeiten … svn commit; rm -rf .hg ist einfacher.) Abgesehen davon, dass das mit git logischerweise ganz genauso funktioniert, büsst man dann aber seine eigenen kleinen Commits ein. Ich will ja am Projekt weiterarbeiten, vielleicht auch meine angefangenen Basteleleien verfolgen und eventuell irgendwann einfließen lassen. Die Mini-Commits kommen ja im svn gar nicht an, weil man die eben in einem der (nur) lokalen Entwicklungs-Branches hat. Die Zwischenergebnisse merged/cherry-picked man in den svn-Branch rüber, kann sie nach Belieben rebasen und zusammenfassen und committed dann nach svn. > Was ich an git absolut nicht leiden kann ist der Evangelismus, der > damit zuweilen betrieben wird … Soll ich dir was sagen? Das ging mir genauso, bis ich mir das mal näher angeschaut habe. Was es letzten Endes besser macht als alle anderen bisher versuchten Systeme ist das zum Einen diese Flexibilität in jede Richtung (es gibt schlicht kein Szenario, welches man nicht irgendwie damit darstellen kann, auch ohne das vorher eingeplant haben zu müssen) und zum Anderen das Mergen. Das geht derart automatisch, dass man überhaupt nicht mehr drüber nachdenkt, an welcher Stelle in welchem Branch man an was rumentwickelt, weil man es einfach ohne manuelle Nacharbeit zusammenmergen und Commits aus dem einen in einen anderen Branch schieben kann. Inzwischen ist es bei mir anders herum: ich kann absolut nicht leiden, wenn geradezu evangelistisch das Festhalten an anderen Systemen gepredigt wird, nur weil man damit ja ebenfalls irgendwie zurechtkommt bzw. weil man es schon immer so gemacht hat. Das wirkt so ein bisschen wie "Früher hatte ich kein Händy, als plötzlich alle eins haben mussten. Und jetzt renne ich diesem Hype namens git genauso nicht nach! *fußaufstampf*". :-)
Johannes S. schrieb: >> Warum sollte man das wollen? Wenn ich es auf den Server zurück >> schreiben will, kann ich doch allemal den svn-Befehl nehmen. > > Du brauchst svn überhaupt nicht dafür, deswegen "sollte man das wollen". > Man muss sich nicht mit beiden Systemen auseinandersetzen. Im Moment muss ich mich mit git (fast) gar nicht auseinandersetzen, und SVN und Mercurial sind (im Gegensatz zu git) "straightforward", wenn man jahrelang CVS gemacht hat. > Abgesehen davon, dass das mit git logischerweise ganz genauso > funktioniert, büsst man dann aber seine eigenen kleinen Commits ein. Ja, aber das ist, nach dem Ende der Experimentierphase, gewünscht. Es folgt dann ein "upstream commit", das die kleinen zusammenfasst. Wenn die Phase noch nicht beendet ist, bleibt es einfach. > Soll ich dir was sagen? Das ging mir genauso, bis ich mir das mal näher > angeschaut habe. Mir umgekehrt: habe mir git angesehen. Ich komm' damit nicht zurecht. Ich nehme es nur dort, wo es zwingend nötig ist (weil das Projekt damit arbeitet). > ... und zum Anderen das Mergen. Das geht derart automatisch, dass > man überhaupt nicht mehr drüber nachdenkt, an welcher Stelle in welchem > Branch man an was rumentwickelt, weil man es einfach ohne manuelle > Nacharbeit zusammenmergen und Commits aus dem einen in einen anderen > Branch schieben kann. Mergen ohne Konflikte ging schon unter CVS ganz automagisch. Haarig wird es immer nur, wenn Konflikte auftreten. Wenn nun in zwei Branches völlig widersprüchliche Dinge passiert sind an der gleichen Stelle, dann musst du zwangsläufig manuell 'ran, das ist bei Mercurial oder git nicht anders. Wenn der eine Branch etwas löscht, was der andere Branch in der Zwischenzeit geändert hat, wie soll das Tool entscheiden, welche der beiden Modifikationen überleben muss? Aber lass uns das lieber in "PC-Programmierung" diskutieren.
Huch, Es ist ja alles so schön alt hier! Ich hab mal ein paar Fragen! Läuft deer SVN - Server überhaupt noch? ;-P Kann man den Svn - Server auch für PC-Anwendungen mißbrauchen, wenn diese zum Thema des Boards passen? Kann man dann auch die fertigen Programme versitionieren, so das jeder, auch wenn er kein Rad Studio hat, auf die *.exe zugreifen kann? Was Open Source ist, weiß ich! Nun arbeitet das Rad Studio objektorientiert. Aber, gilt es auch als Open Source, eine Klasse, die meine Nanny geschrieben hat, als Objekt oder Bibliothek mitzuliefern? mfg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.