Hallo, ich arbeite in einem kleinen Team (<10 Leute) und moechte den Code-Wildwuchs mit einer Versionskontrolle einschraenken. Zur Auswahl stehen SVN und GIT. In der Vergangenheit habe ich viel mit SVN gearbeitet und kenne es daher. In letzter Zeit scheint mir aber GIT in Mode zu kommen. Wenn man nach Vergleichen googelt, zieht eigentlich immer SVN den kuerzeren. Unterschiede, die GIT gegenueber SVN aufweist habe ich folgende gehoert: - dezentrailisiert: GIT can ohne Serververbindung comitten, mergen - Mergen soll viel einfacher sein (paralleles Arbeiten am Code, also mergen, sollte nicht soo oft vorkommen) - Komplizierter zu bedienen als SVN Eingesetzt werden soll das repo zum Speichern von uC Code, der mit MPlab generiert wurde. MPLab bietet out of the box SVN support, aber kein Git wie ich gesehen habe. Ausserdem sollen dort Eagle Layouts und Visual Studio Code gespeichert werden. Gerade bei Eagle waeren Erfahrungen mit Versionskontrollen hilfreich, da habe ich keine. Zu beachten ist auch, dass ich der einzige im Team bin, der schonmal mit Versionskontrollen gearbeitet hat, die anderen kommen hauptsaechlich aus der E-Technik oder auch Maschinenbau, ich will nicht, dass die Einfuehrung daran scheitert, dass Git anfangs fuer die zu kompliziert ist. Jemand Erfahrungen im Einsatz primaer im Embedded Bereich?
Git. Es ist ein bisschen knifflig in git reinzukommen, aber es ist einfach viel durchdachter und moderner als svn und auf lange Sicht sicherlich die bessere Wahl. Insbesondere stört an svn diese total fehlgeleitete Design-Entscheidung, dass "commit" und "push" dasselbe sind... wie falsch das ist, merkt man erst, wenn man von svn auf git wechselt und eine Weile damit arbeitet ;)
Richtig, GIT ist in Mode gekommen. Mehr ist an GIT auch nicht dran, außer dass sich ein paar Nerds über Funktionen ereifern, die die Welt nicht braucht - wenn man nicht gerade einen Kernel baut.
Vergleich einfach mal die Clients für GIT und SVN. Das ist viel wichtiger als das ein oder andere kleine feature. Tortoise SVN als SVN Client für Windows ist sehr schön.
Ppp schrieb: > außer dass sich ein paar Nerds über Funktionen ereifern, die die Welt > nicht braucht - wenn man nicht gerade einen Kernel baut. Ohne es bisher genutzt zu haben - momentan genau meine Meinung. ... schrieb: > Vergleich einfach mal die Clients für GIT und SVN. Das ist viel > wichtiger als das ein oder andere kleine feature. Tortoise SVN als SVN > Client für Windows ist sehr schön. TortoiseSVN kenne ich, afaik gibt es auch TortoiseGIT...
Ich benutze sowohl GIT als auch SVN fast täglich. SVN ist sicherlich einfacher zu erlernen und auch vom Aufbau her anfangs intuitiver, wenn man noch nie mit Versionkontrollsystemen zu tun hatte. Wo SVN allerdings schwächelt, ist die parallele Verwaltung von mehreren Versionszweigen. Bei GIT kann man relativ einfach Änderungen von einem Zweig in einem anderen nachpflegen, um z.B. einen Bugfix-Patch vom Entwicklungszweig in den Produktionszweig zu übernehmen oder auch von mehreren Entwickungszweigen Änderungen in den Hauptzweig zu mergen oder Entwicklungszweige mit dem Hauptzweig zu aktualisieren. Das geht mit GIT deutlich besser als mit SVN.
bobberjahn schrieb: > In der Vergangenheit habe ich viel mit SVN gearbeitet und kenne es > daher. > Zu beachten ist auch, dass ich der einzige im Team bin, der schonmal mit > Versionskontrollen gearbeitet hat, Dann nimm SVN. So hat wenigstens einer den Durchblick und kann den anderen den Weg weisen. Man kann zwar auch Git so verwenden wie SVN, dann hat man aber keine Vorteile. Und um die Vorteile von Git wirklich zu nutzen, sollte wenigstens einer schon einmal ein Projekt damit gemacht haben. Oder er sollte eine Woche Zeit bekommen, sich außerhalb des eigentlichen Projekts mit der Sache intensiv auseinanderzusetzen. > Unterschiede, die GIT gegenueber SVN aufweist habe ich folgende gehoert: > - dezentrailisiert: GIT can ohne Serververbindung comitten, mergen Das ist vor allem dann ein großer Vorteil, wenn die Software nicht nur inhouse entwickelt wird, sondern auch vor Ort beim Kunden Änderungen vorgenommen werden. > - Mergen soll viel einfacher sein (paralleles Arbeiten am Code, also > mergen, sollte nicht soo oft vorkommen) Nicht unbedingt einfacher, aber es gibt mehr Möglichkeiten. Das ist vor allem dann von Bedeutung, wenn man mit stark verzweigten Repositories arbeitet. > - Komplizierter zu bedienen als SVN Um das Gleiche zu tun wie mit SVN, ist die Bedienung ähnlich einfach, oft heißen sogar die Befehle gleich. Manche Dinge gehen mit Git sogar etwas einfacher, bspw. das Anlegen von Branches. > Ausserdem sollen dort Eagle Layouts und Visual Studio Code gespeichert > werden. Gerade bei Eagle waeren Erfahrungen mit Versionskontrollen > hilfreich, da habe ich keine. Verteiltes Entwickeln macht bei Eagle-Layouts und -Schaltplänen wenig Sinn, da nicht vernünftig gemerget werden kann, es sei denn, du hast ein Merge-Tool für Eagle-Dateien. Der Nutzen von SVN oder Git beschränkt sich hier also darauf, eine (lineare) Chronologie der einzelnen Entwicklungsstände zu haben und diese zentral auf einem Server zu halten.
... schrieb: > Vergleich einfach mal die Clients für GIT und SVN. Das ist viel > wichtiger als das ein oder andere kleine feature. Tortoise SVN als SVN > Client für Windows ist sehr schön. Erstaunlicherweise setzt unterdessen sogar MS auf git... http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c Trotzdem: Wenn du SVN kennst nimm SVN, du kannst noch immer später auf GIT wechseln falls nötig. (laut deiner Beschreibung wird dir GIT keine grossen Vorteile bringen) mfg Andreas
Ppp schrieb: > Richtig, GIT ist in Mode gekommen. Richtig. > Mehr ist an GIT auch nicht dran, Falsch. Es würde kein Aufwand in die Entwicklung von Git gesteckt werden, wenn SVN genau die gleichen Möglichkeiten bieten würde. > außer dass sich ein paar Nerds über Funktionen ereifern, die die Welt > nicht braucht - wenn man nicht gerade einen Kernel baut. Der Linux-Kernel war zwar der Anlass für die Entwicklung von Git, das heißt aber nicht, dass dessen Vorteile nur bei der Entwicklung von Linux-Kernels in Erscheinung treten. Ein großer Schwerpunkt bei Git liegt sicher in der dezentralen Entwicklung, die bei kleineren Software- firmen nicht so stark ausgeprägt sein mag. Dezentralität kann aber auch anders aussehen: Ein Beispiel habe ich oben schon genannt: Ich gehe zum Kunden, um vor Ort etwas in Betrieb zu nehmen. Dann habe ich automatisch sämtliche bisherige Versionen der Software mit dabei und kann nach Belieben neue Testversionen (d.h. Branches) anlegen, die ich hinterher ohne Probleme in das Repository auf dem zentralen Server einspielen kann. Ich kann aber auch problemlos meine Änderungen einem Kollegen überspielen, der ebenfalls mit unterwegs ist, ohne dass ich dazu den zentralen Server benötige. Sollte ich am nächsten Tag Urlaub haben, kann der Kollege seine wie meine Änderungen auf den zentralen Server einspielen. Ich verwende Git auch gerne in privaten Softwareprojekten, wo ich der einzige Entwickler bin. Trotzdem arbeite ich mit mindestens drei Repositories, von denen eins auf dem Desktop-PC, eins auf dem Laptop (wenn ich am Wochenende woanders bin) und eins auf dem USB-Stick (für den Datentransport). Mit SVN ist das nicht so einfach, und ich würde mich wahrscheinlich für ein einzelnes Repository auf dem USB-Stick entscheiden. So ein USB-Stick geht aber gerne mal verloren, und damit auch die gesamte Versionsgeschichte, sofern sie nicht regelmäßig gebackupt wurde. Mit den drei parallelen Git-Repositories kann ich mir sogar den Backup sparen. Und dafür muss ich nicht einmal undbedingt einen Git-Server auf einem der Rechner aufsetzen Alles in allem gesehen bietet mir Git eine unglaubliche Freiheit, weil ich überall fast alles machen kann und mir keine große Strategie überlegen muss, an welchem Ort ich ein zentrales Repository halte und wann ich die einzelnen Repositories untereinander synchronisiere.
Und ob Google mit SVN besser beraten wäre als mit Git bei deren Entwicklung, mhhhhhh... :) Da würde mich das administrieren schon schocken
bobberjahn schrieb: > Zur Auswahl > stehen SVN und GIT. Ggf. solltest du noch Mercurial (hg) in Erwägung ziehen: ist von den Ideen her ähnlich wie git (haben gleiche Wurzeln). Teilweise finde ich git aber einfach nur willkürlich anders als vorangegangene VCSe, während hg da gerade von den Begrifflichkeiten noch stärker an CVS oder SVN anlehnt. Manche Dinge in git scheinen schon sehr typisch für die Arbeitsweise der Linux-Kernelentwickler zugeschnitten worden zu sein. hg wird übrigens bei OpenSolaris eingesetzt, man kann also damit durchaus auch eine OS-Entwicklung betreiben. ;-) (Aber das kann man auch mit CVS oder SVN, schließlich gab es auch ein Leben vor dem Tod, ähem, vor git.) Verteilte VCSe haben natürlich auch Nachteile, die man gern ein wenig unter den Tisch fallen lässt. Typischerweise schleppt man ein komplettes Repository pro working copy mit sich rum. Für größere Projekte wird das schnell platzhungrig. Nur so als Vergleich: CVS: working copy braucht nur wenig mehr, als die eigentlichen Daten benötigen SVN: working copy braucht etwas mehr als doppelt so viel wie die eigentlichen Daten, da ein vollständiger Backup des zuletzt ausgecheckten Standes mitgeführt wird git oder hg: working copy braucht Platz für die eigentlichen Daten plus die des gesamten Repos Im Umkehrschluss braucht man bei CVS für praktisch alle Aktionen einen Zugriff auf den Server. Bei SVN gehen "diff" und "revert" lokal, für den Rest braucht man den Server. Bei git oder hg geht alles ohne Server, natürlich nur bis zu dem Stand, zu dem man zuletzt das Repository synchronisiert hat. Yalu X. schrieb: > Es würde kein Aufwand in die Entwicklung von Git gesteckt werden, wenn > SVN genau die gleichen Möglichkeiten bieten würde. Naja, meines Wissens hat Linus Torvalds lange Zeit keinerlei VCS für den Linux-Kernel benutzt, während andere Betriebssysteme schon 20 Jahre vorher für sowas eine Notwendigkeit sahen. Insofern nehme ich ihm den VCS-Experten nicht ab, als der er von seinen Jüngern gern dargestellt wird. Dass verteilte VCSe ihre Vorteile haben, steht außer Frage, aber dass sie das allein seelig Machende sind, halte ich für die allermeisten Projekte für an den Haaren herbei gezogen.
Angehängte Dateien:
-
git_gui.png
120 KB -
git_blame.png
340 KB
Dafür kann git in wenigen Millisekunden die komplette History auflisten oder durchsuchen, oder ohne Netzwerkverbindung sagen wer eine bestimmte Zeile zuletzt modifiziert hat. Plus, man kann komplett offline arbeiten, wenn man das mal will (zum Beispiel im Zug). Oh, oder der Server geht mal nicht -- dann auch. Das klingt nach einer Kleinigkeit, aber wenn man mal in der Situation ist, ist es überraschend nützlich. Nach meiner persönlichen Meinung wiegt das den Nachteil mit der großen Dateigröße locker auf. Für mein Projekt, was History bis zurück zu 2006 und viele tausend Commits hat, sind die komplette Repository gerade mal ein paar Dutzend MB. Plus, git hat eine --depth Option beim clone, was erlaubt auch "shallow" clones einer Repository zu machen, die nicht die komplette History enthalten, sondern nur n Commits (von diesen kann allerdings unter bestimmten Umständen nicht gepusht werden). Ein Problem mit der Größe der Repository kriegt man nur dann, wenn man "un-diffbare", sich oft ändernde Inhalte versioniert, zum Beispiel den aus den Quellen erzeugten Objektcode oder sich häufig ändernde Bilder. Das sollte man aber sowieso nicht machen. Oh, oder dies: Um einem Commit zu machen, muss ich nicht die Änderungen der anderen Leute am Repo berücksichtigen. Das heißt, ich kann meine Arbeit erstmal sichern, und mich dann in aller Ruhe damit beschäftigen, sie mit den Änderungen der anderen zu mergen (indem ich erst git commit und dann git pull benutze). Wenn dabei etwas schiefgeht, kann ich jederzeit zu dem Punkt zurückkehren, bevor ich die Änderungen der anderen mit hineingezogen habe. Bei svn ist das nicht so: Man hat irgendetwas fertig und möchte es commiten, und dann hat irgendjemand dieselbe Datei geändert, und plötzlich ist der perfekt funktionierende Code voller merge conflicts, ehe ich die Chance hatte, ihn durch meinen Commit sozusagen abzusegnen (und zu sichern!). Das ist Murks. Mit git gehe ich meist so vor, wenn ich ein kleineres Feature einbaue: 1) Ich ändere irgendwas am Code. 2) Ich starte git gui (siehe Anhang) und markiere nur einige wenige der gemachten Änderungen für einen neuen Commit. Dabei lasse ich zum Beispiel eingefügte Debug-Statements weg, und versuche, Kram, der in einen Commit kommt, thematisch zu gruppieren. 3) Ich gehe wieder zu 1, solange ich mit dem Endergebnis noch nicht zufrieden bin. 4) Bin ich zufrieden, führe ich oft noch git rebase -i aus und sortiere Commits um, oder führe mehrere zueinandergehörige zu einem Commit zusammen. 5) Erst dann muss ich mich darum kümmern, das ganze mit dem Server zu synchronisieren. Oder auch nicht, wenn ich erst noch weiter testen will, bevor ich das Ganze mit anderen teile. Ebenfalls sehr einfach in git und sehr umständlich in svn: * Schnell mal einen branch erstellen, um etwas auszuprobieren (mit Versionierung!), ohne dies mit anderen zu teilen * Commits zwischen mehreren Branches hin- und herschieben (git merge <branch>, git cherry-pick, ...) * Gerade erst gemachte Commits nochmal schnell ändern (git commit --amend, git rebase -i) * Tags verwalten (git tag) * Nur einzelne Zeilen oder Chunks für einen Commit verwenden (in git kann ich einzelne Zeilen auswählen, die nicht in einem Commit landen sollen!) * Schnell nachsehen, wer und warum eine Zeile zuletzt geändert hat (siehe Anhang) (git blame) * ... Ich habe jahrelang svn benutzt, und war eigentlich immer ganz zufrieden. Dann bin ich irgendwann mehr oder weniger gezwungenermaßen zu git gewechselt, und würde um keinen Preis wieder zurückgehen. ;) Zu hg kann ich keine qualifizierte Meinung äußern, aber ich hab's neulich mal ein paar Stunden benutzt, und ehrlich gesagt kam es mir vor wie git ohne die ganzen coolen Features ;) Andere Leute, mit denen ich gesprochen habe, haben diese Meinung bestätigt. Zugegebenermaßen waren das aber auch eher git-Anhänger. Grüße, Sven
Danke für die ganzen Antworten, das hilft mir schonmal weiter. Jörg Wunsch schrieb: > Ggf. solltest du noch Mercurial (hg) in Erwägung ziehen In meiner Organisation werden derzeit leider nur SVN und Git angeboten :/
Man kann auch SVN Server haben und auf clientseite (wems gefällt) Git verwenden: http://viget.com/extend/effectively-using-git-with-subversion Man kann also durchaus auch beide Welten vereinen. Gerade bei kleinen Teams die in der Regel alle in einem Büro/Firma sitzen würde ich erst mal SVN Empfehlen. Wenn die Leute gar keine Ahnung haben kann git schon sehr verwirrend und frustrierend sein, auch gibt es meist für SVN schon eine Integration in viele Tools für Git wird das mit der zeit auch kommen keine Frage...
Rainbow Dash schrieb: >> Zur Auswahl stehen SVN und GIT. > > Git. > > http://www.youtube.com/watch?v=4XpnKHJAok8 Naja, das ist ungefähr so, wie wenn du für die Frage "Windows oder Linux" einen Vortrag von Bill Gates als Entscheidungsgrundlage nehmen würdest. Wenn nicht einmal der Autor selbst davon überzeugt wäre, dann wär das ja wohl ein ganz schlechtes Omen.
Läubi .. schrieb: > Gerade bei kleinen Teams die in der Regel alle in einem Büro/Firma > sitzen würde ich erst mal SVN Empfehlen. Das Problem ist, dass svn einem total die Idee davon kaputt macht, wie ein VCS eigentlich funktionieren sollte, und wenn man sich erstmal an svn gewöhnt hat, ist es viel schwerer, in git reinzukommen. Da hat Torvalds schon recht -- das war auch genau meine Beobachtung, auch ohne dass ich das Video gesehen hatte. > Naja, das ist ungefähr so, wie wenn du für die Frage "Windows oder > Linux" einen Vortrag von Bill Gates als Entscheidungsgrundlage > nehmen würdest. Klar. Trotzdem ist es sicher kein Fehler, sich die Argumente des Autors mal anzuhören. ;) Man kann ja ergänzend noch ein ähnliches Video über svn anschauen. Grüße, Sven
Sven B. schrieb: > Das Problem ist, dass svn einem total die Idee davon kaputt macht, wie > ein VCS eigentlich funktionieren sollte SVN bietet doch quasi alles was man braucht. Ich denke als VCS taugt es sehr gut (wir haben es hier mit ~600 Kollegen tagtäglich im Einsatz). Privat nutze ich auch GIT, und habe keinerlei Schwierigkeiten beim Umstieg gehabt...
Außer branches, tags, staging area, Commits die nur einige Zeilen enthalten, getrenntes commit/push, "funktioniert auch wenn der Server nicht verfügbar ist", schnelles blame/log, ... ;) Ok -- es gibt anscheinend echt Leute, die das nicht nutzen, obwohl sie es kennen. Ich kann das nicht ganz nachvollziehen, aber ich gebe zu: svn ist das einfachere der beiden Systeme. Nur, wie erwähnt, denke ich dass die Vereinfachungen den Verlust an Funktionalität nicht aufwiegen.
Sven B. schrieb: > Außer branches, tags... Äh? SVN hat keine Branches? keine Tags? Hast du überhaupt schon mal damit gearbeitet?
Quibbes schrieb: > Sven B. schrieb: >> Außer branches, tags... > > Äh? SVN hat keine Branches? keine Tags? > Hast du überhaupt schon mal damit gearbeitet? SVN hat keine client-Side Branches. Alle Branches müssen zwingend auf den Server. Das finde ich persönlich doof, da man dann nicht mal eben einen kleinen Branch erstellen kann um mal was zu testen.
Rainbow Dash schrieb: > SVN hat keine client-Side Branches. Alle Branches müssen zwingend auf > den Server. Das finde ich persönlich doof, da man dann nicht mal eben > einen kleinen Branch erstellen kann um mal was zu testen. Da hast du allerdings Recht. Hier ist GIT im Vorteil. Allerdings kann man auch ohne diese Funktionalität leben, als Killerfeature würde ich es also nicht bezeichnen. Macht das Leben eben nur ein bisschen einfacher ;-)
Ja, jahrelang. Aber verglichen mit dem, was git unter Branches und Tags versteht, ist das meiner Meinung nach Murks. ;) In git ist halt branches echt so einfach: git branch experimental_feature git checkout experimental_feature ... git commit ... git checkout master ... Und das ist alles lokal. Nix mit "svn copy", und so ein branch braucht auch nur wenige Bytes Speicher. Ich kann nach einem halben Jahr in dem Branch "git rebase master" machen. Ich kann aus dem Branch weitere Branches abzweigen. etc Tags macht man in svn ja auch mit copy. In git kann man einfach git tag v1.4.0 HEAD machen. Das ist wieder eine Operation, die nur wenige Bytes Speicher benötigt. Will sagen: git branch / git tag sind zwei Tools, die speziell für tags und branches gebaut sind und perfekt funktionieren. Bei svn sind das nur irgendwelche Workarounds. Dass es offizielle Workarounds sind, macht die Sache nicht besser. Wofür ich das branch feature zum Beispiel oft nutze, ist um irgendein Feature zu bauen, von dem ich nicht weiß, ob es funktionieren wird, oder ob es vielleicht Quatsch ist. Sowas will ich nicht als Kopie der Repository auf dem Server haben. Grüße, Sven
Sven B. schrieb: > Ich kann nach einem halben Jahr in dem Branch "git rebase > master" machen. Aber eben auch nur, wenn die beiden nicht gerade grundlegend auseinandergelaufen sind. Solange es keine Konflikte gibt, ist ein Merge (rebase, wie auch immer) immer recht einfach. Allerdings ist es richtig, Branches in git oder hg sind sehr viel leichtgewichtiger als in CVS oder SVN. Andererseits kann man für lokale Experimente immer noch über eine SVN working copy ein git oder hg lokal drüberlegen. ;-) Für die genannten Dinge (lokale Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS dann auf dem zentralen Master läuft.
Jörg Wunsch schrieb: > Sven B. schrieb: >> Ich kann nach einem halben Jahr in dem Branch "git rebase >> master" machen. > > Aber eben auch nur, wenn die beiden nicht gerade grundlegend > auseinandergelaufen sind. Solange es keine Konflikte gibt, ist > ein Merge (rebase, wie auch immer) immer recht einfach. Stimmt, aber das ist ein Problem der Sache an sich und nicht Schuld oder Aufgabe des VCS. Was ich damit sagen wollte, git bietet die Funktionalität um diesen Prozess so einfach wie möglich zu gestalten, nämlich "git rebase master", was ungefähr eine Viertelsekunde dauert. > Andererseits kann man für > lokale Experimente immer noch über eine SVN working copy ein git > oder hg lokal drüberlegen. ;-) Für die genannten Dinge (lokale > Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS > dann auf dem zentralen Master läuft. Hahaha, das stimmt natürlich, aber ob das so das optimale Modell ist, bezweifle ich einfach mal. Ich hab' das auch schon gemacht... aber wenn es sich vermeiden lässt, ist es natürlich besser. Grüße, Sven
Sven B. schrieb: > Das Problem ist, dass svn einem total die Idee davon kaputt > macht, wie ein VCS eigentlich funktionieren sollte Wer bestimmt eigentlich wie "es" funktionieren sollte? Der "Erfinder" von GIT? Sven B. schrieb: > Außer ... Alles schön und gut, aber wenn man es braucht weil man sich irgendwie erleuchtet fühlt kann man ja git-svn nutzen, aber wie gesagt wenn eh alle im gleichen Haus/Büro sitzen bringt mir das alles nichts, und der Verwaltungsoverhead ist auch geringer da eh jeder auf den Zentralen Server commiten "muss"... Sven B. schrieb: > Ich kann nach einem halben Jahr in dem Branch > "git rebase master" machen Wenn nicht zwischenzeitlich die Festplatte/USB Stick o.ä. verlorengegangen ist wo dein alleiniger lokaler branch liegt. Gerade in Firmen ist es einfach nicht so, dass jeder "mal so zum testen" rumwerkelt sondern wenn dann arbeitet man oft gemeinsam auf einem Bugfix Stand und den will man sowieso zentral haben auf dem Server haben und nicht irgendwo auf dem USB Stick des Entwicklers der mit diesem gerade im Zug Richtung Süden für einen zweiwöchigen Urlaub sitzt ;-) Für stark verteilte (z.B. gemeinschaftliche OS Projekte) ist git eine gute Sache, für "lokale" Entwicklung bringt es erstmal nur Verwaltungsoverhead mit sich und der einzelne Entwickler kann ja mit git arbeiten wenn er den unbedingt sich persönlich entfalten will (siehe git-svn)...
Sven B. schrieb: > Hahaha, das stimmt natürlich, aber ob das so das optimale Modell ist, > bezweifle ich einfach mal. Hat durchaus auch Vorteile: man muss sich bei den commit messages nicht weiter große Mühe geben, da sie eben auch nur lokal sind. Wenn man dann die komplette Änderung zurück zum Master bringt, "compiliert" man sich daraus eine politisch korrekte commit message fürs zentrale VCS. Wenn sich der ganze experimentelle Branch als großer Murks herausstellt, macht man einfach ein rm -rf .hg (oder .git), und gut' ist's.
Hi, Läubi .. schrieb: > Sven B. schrieb: >> Das Problem ist, dass svn einem total die Idee davon kaputt >> macht, wie ein VCS eigentlich funktionieren sollte > Wer bestimmt eigentlich wie "es" funktionieren sollte? Der "Erfinder" > von GIT? Ich bestimme das, weil ich muss es ja schließlich auch benutzen. Du kannst natürlich eine andere Meinung davon haben, wie ein VCS funktionieren sollte. > Sven B. schrieb: >> Außer ... > Alles schön und gut, aber wenn man es braucht weil man sich irgendwie > erleuchtet fühlt kann man ja git-svn nutzen, aber wie gesagt wenn eh > alle im gleichen Haus/Büro sitzen bringt mir das alles nichts, und der > Verwaltungsoverhead ist auch geringer da eh jeder auf den Zentralen > Server commiten "muss"... Mache ich auch, wenn ich mal mit einem svn-Projekt konfrontiert werde. Viele gibt es zum Glück nicht mehr. ;) > Sven B. schrieb: >> Ich kann nach einem halben Jahr in dem Branch >> "git rebase master" machen > Wenn nicht zwischenzeitlich die Festplatte/USB Stick o.ä. > verlorengegangen ist wo dein alleiniger lokaler branch liegt. Ich kann den Branch auch problemlos irgendwohin pushen -- andere Leute merken nichts davon, wenn sie nicht explizit diesen Branch anfordern. > Gerade in Firmen ist es einfach nicht so, dass jeder "mal so zum testen" > rumwerkelt sondern wenn dann arbeitet man oft gemeinsam auf einem Bugfix > Stand und den will man sowieso zentral haben auf dem Server haben und > nicht irgendwo auf dem USB Stick des Entwicklers der mit diesem gerade > im Zug Richtung Süden für einen zweiwöchigen Urlaub sitzt ;-) Wenn man Code schreibt, ist das -- zumindest bei mir -- immer "mal so zum testen". In den meisten Situationen finde ich es schwer, vorher zu beurteilen ob das Endergebnis sowohl vom Code als auch von der Funktionalität her akzeptabel sein wird, und finde es deshalb von Vorteil, den Kram in einem eigenen Branch (ob lokal oder mit irgendeinem Server synchronisiert) ausprobieren zu können, ohne andere dabei zu stören. Bei Bugfixes ist das natürlich alles etwas einfacher, aber Entwicklung an einer Anwendung besteht ja nicht nur aus Bugfixes. > Für stark verteilte (z.B. gemeinschaftliche OS Projekte) ist git eine > gute Sache, für "lokale" Entwicklung bringt es erstmal nur > Verwaltungsoverhead mit sich und der einzelne Entwickler kann ja mit git > arbeiten wenn er den unbedingt sich persönlich entfalten will (siehe > git-svn)... Hm, das verstehe ich nicht ganz? Also meine Projekte fangen immer damit an, dass ich einen leeren Ordner anlege und dort "git init" ausführe. In den meisten Fällen kommt dann eh nur Murks raus, und ich vergesse das Ganze. Wenn's doch was wird, pushe ich die Repository irgendwann auf github oder so. Das muss ich mir aber nicht überlegen, bevor ich das Projekt beginne -- ich kann alles lokal machen, und dann irgenwann die komplette History pushen. Das geht mit svn sicher auch irgendwie, aber bei git ist es so entworfen, dass das so funktioniert, und es ist auch dementsprechend einfach (nämlich quasi kein Aufwand, zwei Kommandos oder so). Grüße, Sven
Sven B. schrieb: > Ich bestimme das, weil ich muss es ja schließlich auch benutzen. Naja, aber eben deshalb finde ich (private Meinung) das gerangel um ein "besseres" oder "richtigeres" VCS quatsch. Sven B. schrieb: > In den meisten Fällen kommt dann eh nur Murks raus, und > ich vergesse das Ganze. Wenn's doch was wird, pushe ich > die Repository irgendwann auf github oder so Das ist aber halt meist nicht der Prozess welchen man in einem (Firmen-)Team hat. Und so hört es sich beim TE aber an, deswegen sage ich ja für verteilte (OS) Projekte ist git sicher das Mittel der Wahl, es als Allheillösung oder "besseres SVN/CSV/..." anzupreisen meiner Meinung nach aber nicht zielführend.
Hi, Manchmal unterscheiden sich Meinungen, weil es tatsächlich unterschiedliche Meinungen sind. Oft aber unterscheiden sie sich auch, weil die Person A mit Meinung A einfach ein paar wichtige Sachen nicht verstanden hat, die Person B mit Meinung B weiß. Und wenn Person B der Person A diese Sachen erklärt, würde A seine Meinung vielleicht ändern. Aus diesem Grund finde ich es nicht unsinnig, über solch ein Thema zu diskutieren, auch wenn es im Endeffekt Geschmackssache ist, welches VCS man bevorzugt. (Ich möchte damit nicht sagen, dass ich mich mit Person B identifiziere) > Das ist aber halt meist nicht der Prozess welchen man in einem > (Firmen-)Team hat. Zum einen kann man git genau so nutzen wie svn: wenn man git commit und git push immer zusammen verwendet und branches immer pusht, gibt's da nur wenig Unterschiede. Bis darauf, dass git schneller ist. Zum anderen ... siehe Anfang meines Beitrags. Vielleicht läuft das nur so ab, weil es sowieso keine andere Möglichkeit gibt, und vielleicht würde es besser funktionieren, wenn es anders wäre. Vielleicht. Grüße, Sven
Jörg Wunsch schrieb: > Andererseits kann man für > lokale Experimente immer noch über eine SVN working copy ein git > oder hg lokal drüberlegen. ;-) Für die genannten Dinge (lokale > Branches, lokale Commits) ist es ja völlig unabhängig, welches VCS > dann auf dem zentralen Master läuft. Wenn die Entwickler in Git so gut eingearbeitet sind, dass sie es gewinnbringen lokal benutzen können, spricht eigentlich wenig dagegen, es auch serverseitig zu verwenden. Ja, ich habe deinen Smiley schon gesehen und liefere deswegen ebenfalls einen ;-) Bei bobberjahn ist jedoch die Situation die, dass er SVN bereits kann, Git aber noch nicht. Deswegen habe ich ihm weiter oben vorgeschlagen, erst einmal bei SVN zu bleiben (auch wenn ich persönlich lieber Git benutze). Er verzichtet damit zwar auf die tollen Git-Features, aber das heißt ja nicht, dass man mit SVN nicht ebenfalls produktiv arbeiten kann (bei Git würde auf Grund der Einarbeitung erst einmal eine unproduktive Phase entstehen).
Yalu X. schrieb: > Wenn die Entwickler in Git so gut eingearbeitet sind, dass sie es > gewinnbringen lokal benutzen können, spricht eigentlich wenig dagegen, > es auch serverseitig zu verwenden. Ich schrieb ja "git oder hg". In meinem Falle komme ich mit git rein gar nicht zurecht (weil "alles ganz anders ist"), mit hg dagegen sehr wohl. (hg wiederum steht dem TE nicht zur Verfügung.) Außerdem hat diese Vorgehensweise den Vorteil, dass gewissermaßen SVN der kleinste gemeinsame Nenner zwischen allen beteiligten Entwicklern ist, aber diejenigen, die die erweiterten Möglichkeiten eines DVCS nutzen wollen, das per Overlay trotzdem tun können (ohne dass die anderen überhaupt was davon merken).
Ein riesiger Vorteil von SVN gegenüber GIT sind die Locks. Unter GIT gibt es keine Möglichkeit, Konflikte zwischen verschiedenen Anwendern beim Bearbeiten von Binärdateien zu vermeiden (zumindest sind mir keine bekannt). Aus diesem Grund führt bei uns in der Firma nach wie vor kein Weg an SVN vorbei.
Sven B. schrieb: > Verstehe ich nicht. Kannst du die Situation mal genauer erklären? Ich kann's versuchen ;-) Stell dir vor im repo ist ein Word Dokument abgelegt. GIT: Alice ändert lokal bei sich was an diesem Dokumnet. Bob ändert ebenfalls was an diesem Dokument bei sich auf dem Rechner. Nun comitted und pusht Alice ihr Dokument ins Zenral-repo. Bob steht jetzt dumm da, weil er Binärdateien nicht mergen kann. Nun muss er entweder die Datei von Alice nehmen, und seine Änderungen nochmal machen, oder Alices Datei überschreiben und sie auffordern ihre Änderungen nochmal zu machen. SVN: Alice will das Word Dokument bearbeiten. dazu muss sie sich das Lock holen, und kann loslegen. Nun möchte auch Bob das Dokument verändern. Hier verhindert SVN, dass Bob auch ein Lock bekommt. Er bekommt die Nachricht, dass Alice gerade das Dokument bearbeitet, und dass er warten muss. Erst wenn Alice fertig ist darf Bob auf dem aktualisierten Word-Dokument weiterarbeiten. => Es kann nichts passieren, keine Arbeit wird unnötig gemacht und muss später verworfen werden Ich hoffe das war einigermaßen verständlich?
Ja, ok. Sowas geht mit git tatsächlich nicht, weil es halt als Versionierungssystem gedacht ist für Dateien die sich auch tatsächlich versionieren lassen -- was bei Word-Dokumenten ohne weiteres nicht der Fall ist ;) Grüße, Sven
mindestens ebenso entscheidend wie der funktionsumfang eines vcs ist die akzeptanz der mitarbeiter die angebotenen funktionen auch zu nutzen. wir haben es unseren starentwicklern in 10 jahren nicht beibringen können produktions- und testingflags zu setzen oder files zu branchen.
Wie sieht es bei GIT aus zwecks looks ? Wenn die aktuelle SW ein review gemacht wird, ein Build eingefroren werden muss, weil es releast wurde und die sourcen so bleiben müssen wie es releast wurde, usw , wie geht das bei GIT ? Bei SVN lookt man den Build/branch/... und gut is. Auch z.B. Keys, ein Beispiel für Bootloader verschlüsselung, usw, sollten nicht änderbar sein. Wie wird das in GIT gemacht ?
Ich sehe nicht wirklich, warum man das machen muss? Man macht z.B. einen Branch für ein stable release und sagt den Leuten "keine Feature-Commits in diese Branch". Wenn man ein Release macht, macht man einen Tag dafür, dann kann man den Stand bei diesem Tag jederzeit nachsehen. Das mit dem Schlüssel verstehe ich noch weniger. Wenn der nicht geändert werden soll, dann ändert ihn halt niemand. Wo ist das Problem? Wenn du sowas technisch erzwingen willst, kannst du einen Commit-Hook bauen. Grüße, Sven P.S.: Das Wort heißt "lock" ;)
Sven B. schrieb: > sagt den Leuten "keine Feature-Commits > in diese Branch" Sven B. schrieb: > Wenn der nicht geändert > werden soll, dann ändert ihn halt niemand Sinn und Zweck eines VCS ist es ja, die Entwickler im Zaum zu halten. Mündliche Absprachen sollten da eigentlich nicht notwendig sein ;-) Insofern ist es schon gut, wenn das VCS alles Unerwünschte unterbindet... Das mit den Hooks sagt mir jetzt nicht, viel, geht aber vermutlich in diese Richtung?
Klabauter schrieb: > Sinn und Zweck eines VCS ist es ja, die Entwickler im Zaum zu halten. Da bin ich anderer Meinung. Sinn eines VCS ist, ein möglichst flexibles Werkzeug zur Versionierung für den Entwickler zu sein. > Mündliche Absprachen sollten da eigentlich nicht notwendig sein ;-) Naja, du kannst doch kein Release einer Anwendung machen, indem du deinem VCS sagst "ab jetzt darf keiner mehr in diesen Branch schreiben"... wie soll das denn funktionieren. Natürlich müssen sich die Entwickler mündlich absprechen, dass sie dann und dann ein Release mit den und den Features machen wollen. > Insofern ist es schon gut, wenn das VCS alles Unerwünschte > unterbindet... Unerwünscht, wie zum Beispiel...? Die Entwickler müssen schon selbst entscheiden, wann sie in einen Branch schreiben wollen oder nicht. Wer soll das sonst entscheiden -- der Server-Admin? Wieso sollte der das besser wissen als die Entwickler? Wer nicht will, dass jemand anders dazwischen funkt, kann sich ja selbst eine Kopie vom Repo anlegen und nicht pullen -- das ist ja das tolle an "verteilt" ;) > Das mit den Hooks sagt mir jetzt nicht, viel, geht aber vermutlich in > diese Richtung? Du kannst ein Skript schreiben, was irgendwelche Checks macht, bevor ein Commit vom Server akzeptiert wird, und wenn das Skript nicht zufrieden ist, lehnt es den Commit ab. Die KDE-Server akzeptieren zum Beispiel keine Commits, die Objektcode enthalten. Auf die Art ist es natürlich auch möglich, ganze Branches oder Repos zu sperren -- oder Dateien. Grüße, Sven
Sven B. schrieb: > Unerwünscht, wie zum Beispiel...? Bei uns Z.B. wenn ein großer Merge eines Branches in den Haupt-Branch durchgeführt werden soll. Das kann durchaus mehrere Tage dauern, während derer der Branch für die Entwickler gesperrt wird um zusätzliche Komplikationen zu vermeiden. Sven B. schrieb: > Die Entwickler müssen schon selbst entscheiden, wann sie in einen Branch > schreiben wollen oder nicht. Wer soll das sonst entscheiden Wir haben dafür ein Team von Leuten, die sich um das Branching und die Merges kümmern. Der einzelne Entwickler hat da nichts dran zu tun... Ich merk schon, die Prozesse laufen bei euch deutlich anders als bei uns ;-)
chris schrieb: > Wie sieht es bei GIT aus zwecks looks ? > Wenn die aktuelle SW ein review gemacht wird, ein Build eingefroren > werden > muss, weil es releast wurde und die sourcen so bleiben müssen wie es > releast > wurde, usw , wie geht das bei GIT ? Bei SVN lookt man den > Build/branch/... > und gut is. > Auch z.B. Keys, ein Beispiel für Bootloader verschlüsselung, usw, > sollten nicht änderbar sein. Wie wird das in GIT gemacht ? Mit Tags. Tags können im Nachhinein nicht verändert werden. Zusatz Empfehlung: einen Branch für jedes release, sodass bugfixes genau auf dem Branch eingepflegt werden können (und dann ohne probleme auf den master/Head/trunk branch gezogen werden können)
bobberjahn schrieb: > Eingesetzt werden soll das repo zum Speichern von uC Code, der mit MPlab > generiert wurde. MPLab bietet out of the box SVN support, aber kein Git > wie ich gesehen habe. Ausserdem sollen dort Eagle Layouts und Visual > Studio Code gespeichert werden. Gerade bei Eagle waeren Erfahrungen mit > Versionskontrollen hilfreich, da habe ich keine. Damit Du Eagle vernünftig mit einer Versionsverwaltung einsetzen kannst, ist ein Update auf die Version 6 notwendig. Ab dieser Version werden alle Dateien (sch/brd/lbr) als XML abgespeichert und nicht mehr als Binärblobs. Das heißt dann auch: Erst ab dieser Version kann eine Versionsverwaltung ein richtiges diff machen und bei Änderungen nur die Deltas abspeichern anstelle des gesamten Blobs. Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben. fchk
Ich arbeite nicht als Software-Entwickler, ich kenne das nur aus der Open-Source-Welt ;) Aber ja, sowas läuft bei git tatsächlich deutlich anders. Das Video von Torvalds von weiter oben aus dem Thread behandelt genau diese Unterschiede relativ ausführlich. Er beschwert sich auch sehr laut darüber, dass es bei CVS & Co immer extra Leute gibt, die sich um das Branching kümmern müssen ;) In git würde halt irgendjemand den Merge von einem Branch vornehmen, und zwar lokal -- der Branch müsste dafür dann nicht gesperrt werden, denn wenn sich etwas ändert, kann man einfach, nachdem der erste Merge abgeschlossen ist, noch einen Merge machen. Der wird dann ja in der Regel sehr einfach sein. Git kümmert sich darum, dass nicht dieselben Änderungen zweimal gemerged werden. Grüße, Sven
Frank K. schrieb: > Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit > Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben. Wobei natürlich ein Merge von XML-Daten trotzdem noch heikel ist. Je nach Änderungen kann die Benutzbarkeit des Ergebnisses durchaus sehr unterschiedlich ausfallen. ;-) Aber natürlich allemal besser als reine Binärblobs.
Jörg Wunsch schrieb: > Frank K. schrieb: >> Beim Update musst Du darauf achten, dass Du ALLE sch/brd/lbr einmal mit >> Eagle 6 lädst und neu speicherst, um alles als XML vorliegen zu haben. > > Wobei natürlich ein Merge von XML-Daten trotzdem noch heikel ist. > Je nach Änderungen kann die Benutzbarkeit des Ergebnisses durchaus > sehr unterschiedlich ausfallen. ;-) Aber natürlich allemal besser > als reine Binärblobs. DANKE für diese Info. Ich hab das jetzt mehrmals hier im Forum gelesen, dass das so toll sei, dass EAGLE jetzt in einem menschenlesbaren Format abspeichert und man viel besser die SVN Features nutzen kann. Und jedes mal habe ich mich beispielsweise gefragt, was passiert, wenn der eine ein Bauteil hinzufügt und jemand zweites ein anderes Bauteil einfügt, die im Board beispielsweise an die gleiche Position platziert werden. Das gibt doch das totale Durcheinander.
Das Problem ist, dass die Merge-Funktionalität zeilenweise arbeitet. Für XML müsste sie aber auf der Ebene von XML-Elementen arbeiten, völlig unabhängig davon, ob nun alle XML-Elemente auf einer Zeile stehen oder "klassisch" eingerückt sind. Konflikte wie deiner würden natürlich trotzdem nicht erkannt, da das sich ergebende XML zwar valide ist, aber sinnlos.
Naja, das Zeilen-Problem ließe sich evtl. mit einem Commit Hook lösen, der das XML in ein für den Merge passendes Format bringt.
Es bleibt meiner Meinung nach nach wie vor sinnlos, so etwas zu tun. Also warum sollte man das XML Problem lösen?
Ich glaube auch nicht, dass es sinnvoll ist, Schaltpläne im XML-Format auf Textebene zu mergen: - Dinge, die im Schaltplan logisch eng miteinander verknüpft sind, stehen in der XML-Datei nicht unbedingt eng beieinander, so dass Konflikte nur schwer erkennbar sind. - Bei einem gewöhnlichen Quellcode-Merger kann es passieren, dass das Merge-Ergebnis so verhunzt ist, dass es von Eagle nicht mehr gelesen wird. Man müsste dann die Korrekturen manuell auf XML-Ebene durchfüh- ren. - Auch ein manuelles Mergen auf XML-Ebene ist praktisch unmöglich, da die logischen Zusammenhänge der Schaltung aus dem XML-Text praktisch überhaupt nicht ersichtlich sind. Ein spezielles Eagle-Merge-Tool würde diese Probleme prinzipiell lösen, aber selbst dann ist es für einen Entwickler sehr aufwendig, das Merge- Ergebnis auf elektrische Korrektheit zu prüfen. Da er nicht weiß, wo genau die Änderungen gemacht wurden, müsste er nach jdem Merge jedes Detail der Schaltung aufs Neue überprüfen. Bei Platinenlayouts wird die Sache noch schwieriger, da dort eine kleine Änderung (wie bspw. das Verschieben eines Bauteils um 1 mm oder die Verbreiterung einer Leiterbahn) einen ganzen Rattenschwanz an weiteren Änderungen (bspw. das Verschieben vieler Leiterbahnen, Vias u.ä. in der Umgebung) nach sich zieht. Gleichzeitige Änderungen von mehreren Entwicklern werden deswegen fast immer zum Konflikt führen. Wesentlich sinnvoller als ein automatischer Merger wäre ein interaktives Tool, das die Unterschiede zwischen zwei Schaltplänen in einem grafischen Editor farblich hervorhebt und dem Benutzer die Möglichkeit bietet, jeden dieser Unterschiede in die neue Version zu übernehmen oder zu verwerfen. So ein Tool müsste aber wohl erst noch geschrieben werden. Solange es dieses Tool nicht gibt, ist es am besten, den Schaltplan (bzw. bei modular aufgebauten Schaltplänen jedes Modul) und das Layout immer nur ein einem Entwickler gleichzeitig bearbeiten zu lassen. Es ist die Aufgabe des Projektleiters, jeweils einen geeigneten Entwickler zu bestimmen, der für eine bestimmte Änderung zuständig ist. Dann muss die Datei auch nicht gelockt werden.
Oder sowas wie gobby oder Google Docs, was Bearbeiten eines Dokumens von mehreren Leuten gleichzeitig erlaubt und die Änderungen der anderen Personen sofort darstellt.
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.