Gibt es eine einfache zu handhabende Versionsverwaltung für den PC (Windows)? Ich möchte gerne Pythonskripte offline verwalten. Merten
git Unterstützung dafür ist vmtl. im Editor/IDE, die du zum Erstellen deiner Scripte verwendest schon vorhanden oder per Plugin verfügbar. Beachte: "git" ist nicht "github". Das geht auch völlig lokal und cloud-frei.
Besser ist git auch nur, wenn man es braucht. Und mit git muß man sich deutlich länger beschäftigen als mit SVN.
Wenn Du was einfaches brauchst, nimm svn. svn ist zentralistisch, lagert alle Dateien auf einem zentralen Repository (lokal oder im Netz), und jeder der was davon braucht, verbindet sich mit diesem Repository über svn:// oder http(s)://. git ist ein verteiltes System, bei dem Du lokale und entfernte Repositories hast, lokal arbeitest, dich aber auch mit Netzwerkrepositories synchronisieren kannst. git kann deutlich mehr, ist aber auch deutlich komplexer und aufwändiger. Wenn Du die Features von git brauchst, nimm es. Wenn nicht, nimm svn. Man kann svn und git Repositories auch miteinander synchronisieren. Wenn Du jetzt mit svn anfängst und später merkst, dass das nicht reicht, kannst Du immer noch migrieren, ohne die Versionshistorie zu verlieren. Was anderes als svn und git spielt heutzutage fast keine Rolle mehr. rcs ist Asbach, cvs auch, Visual SourceSafe willst Du nicht (und will Microsoft auch nicht mehr), und MKS und Perforce ... es gibt sie. fchk
Wühlhase schrieb: > Besser ist git auch nur, wenn man es braucht. Und mit git muß man > sich deutlich länger beschäftigen als mit SVN. Lese ich immer wieder, nur irgendwie konnte mir noch keiner aufzeigen, wieso SVN einfacher sein sollte. Es ist schlichtweg deutlich umständlicher und heutigen Anforderungen nicht mehr gewachsen. https://www.atlassian.com/git/tutorials/setting-up-a-repository Oder ist ein git init git add dummedatei.txt git commit -m "initiLer commit' Wirklich so schwer und kompliziert?
Der Vorteil bei Tortoise (SVN auf einem Windows PC): Du installierst Tortoise/SVN auf Deinem Rechner, nimmst einen leeren Ordner und eröffnest dort mit der rechten Maustaste ein neues Repository. Ohne Webgedöns, Server oder was weiß ich. Innerhalb von Minuten kannst Du lokal loslegen, notfalls ohne Internet auf einem Uraltrechner. Du kannst Dich dann in SVN reinfuchsen, Du kannst aber auch alles mit der rechten Maustaste machen. Das erleichtert den Einstieg ungemein.
Peter Pan schrieb: > git init > git add dummedatei.txt > git commit -m "initiLer commit' > > Wirklich so schwer und kompliziert? Das ist ja nur der Anfang. Szenario: Ich habe einen Haufen versionierter Dateien mit lokalen Änderungen, die ich auf einem Repository auf einem Server einchecken will. svn: svn ci -m "text" git: git add -all && git commit -m "text" && git push Bei SVN habe ich kein lokales Repository (außer ich lege mir eines an), sondern nur meine Working Copy. Bei git comitte ich immer erstmal ins lokale Repo (das dann mindestens so viel Platz wie meine Working Copy braucht) und muss das dann nochmal extra pushen. Klar. Sind unterschiedliche Konzepte. Das muss man verstanden haben und je nach Use Case seine Wahl treffen. fchk
Eindeutig git; SVN ist von vorgestern, würde ich niemandem mehr empfehlen. In seiner vollen Schönheit ist es tatsächlich komplexer und umfangreicher mit Cherry-Pick, Squash, Bisect und was es da alles gibt, aber... muss man ja nicht nutzen. Für einfache Projekte reicht init, add, commit (wie oben geschrieben), das wars. Wer will, kann dann noch TortioseGit nehmen, dann ist es "genau so" wie SVN, man kann aber immer noch weiter skalieren (IDE-Einbindung, Github, verteilte Repos für's Notebook auf der Bahnfahrt, etc.)
Peter Pan schrieb: > Lese ich immer wieder, nur irgendwie konnte mir noch keiner aufzeigen, > wieso SVN einfacher sein sollte. Nichts für ungut, aber es scheint so als hättest du den Unterschied zwischen git und SVN nicht begriffen. Bei SVN kannst du dich z.B. nicht zwischen mehreren Branches verirren, wenn man überhaupt erst einmal weiß was ein Branch (in git) ist. Und selbst wenn man dann weiß wie das alles in git funktioniert, dann gibt es immer noch genug Strategien zur Auswahl mit Branches zu arbeiten. SVN ist allein in dieser Hinsicht deutlich intuitiver und schneller zu verstehen. Peter Pan schrieb: > Es ist schlichtweg deutlich umständlicher und heutigen Anforderungen > nicht mehr gewachsen. Nicht alle Anforderungen, die es heute in dem ein oder anderen Projekt gibt, werden auch vom TS gestellt. Im Gegenzug darfst du jetzt aber mal erklären, warum SVN umständlicher sein soll. Peter Pan schrieb: > https://www.atlassian.com/git/tutorials/setting-up-a-repository > > Oder ist ein > > git init > git add dummedatei.txt > git commit -m "initiLer commit' > > Wirklich so schwer und kompliziert? Einen Fahrschüler wirst du hoffentlich auch nicht in seiner ersten Fahrstunde sofort ohne Aufsicht auf die Autobahn lassen, nur weil er auf Anhieb den Motor starten kann. Git kann ja auch deutlich mehr als nur eine Datei hinzuzufügen, oder? Ach ja...was machst du mit deiner Änderung jetzt eigentlich? Pushen, oder Committen? Bei SVN ist das ja einfach, aber selbst in proffessionellen Programmierteams soll es vorkommen, daß jemand den Unterschied vergißt. Und das eine bleiben läßt. Und wenn der TS dann doch einen zentralen Server haben will...wird git alles andere als intuitiv.
Frank K. schrieb: > git: git add -all && git commit -m "text" && git push Das würde ich keinem empfehlen. Ich schaue immer erst mit "git status", was hat sich überhaupt geändert. Manchmal nehme ich "git add -u", wenn ich nur Dateien im Repo geändert habe, um die alle in einem rutsch dazu zu tun. Der Rest füge ich dann mit "git add datei/verzeichnis". Dann checke ich mit "git status" was ich da ausgewählt habe, und manchmal noch mit "git diff --cached" dass ich wirklich all die Änderungen will / ich da nichts versaut habe. Dann mache nehme ich eventuell manche files wieder raus, oder ändere noch was. Und dann mach ich den "git commit". Aber "git add --all", brauche ich absolut nie. Da fällt mir auf, im Zitat oben machst du das falsch --all, nicht -all. Das --all ist aber sowieso unnötig, wenn man alle Dateien in einem Ordner dazutun will, kann man einfach "git add ." nehmen, "." für den aktuellen Ordner. Und wenn man im im Projektordner oben ist, ist das sowieso alles, wie bei --all. Ich hab zwar noch eine .gitignore, normalerweise kommt also nichts unnötiges rein, auch bei "git add --all". Aber nachsehen sollte man trotzdem immer nochmal. Sonst wird das Repo schnell mal versehentlich zur Müllhalde. Und das später nachbessern, auch in der Historie, würde ich niemandem zumuten wollen. PS: Noch was tolles an git, du kannst auch lokal irgendwo Repos hin tun. "mkdir repo.git; cd repo.git; git init --bare" und dann im Projekt "git remote add lokalrepo /pfad/zum/repo.git; git push -u lokalrepo master". Man kann das dann natürlich auch wieder clonen. "git clone /pfad/zum/repo.git" Projektordnername. Ist auch praktisch, um mit mehreren Repos/Remotes für ein Projekt umgehen zu lernen. PPS: In neuerem Git ist der default branch manchmal "main" statt "master". Man kann die aber alle beliebig nennen.
Merten schrieb: > Ich möchte gerne Pythonskripte offline verwalten. Noch ein git von mir. Wie bereits gesagt, git ist local und hat mit github nur in sofern etwas zu tun, dass es die lokale Voraussetzung dafür ist. Womit schreibst du den Python Code? Auch wenn die rudimentäre Benutzung von git schnell erlernt ist, liebe ich die Unterstützung, die VSCode bietet. Gerade wenn es um die grafische Darstellung der Branches geht.
Kommt vielleicht etwas auf die IDE an. Es geht z. B. kaum einfacher als mit der Kombination VSCode + git. Auch sonst ist git SVN in fast allen Aspekten überlegen. Wenn man sowieso eine gewisse Affinität zur Kommandozeile hat, dann auf jeden Fall git. Für SVN spricht aber das sehr gute Windows-Frontend "TortoiseSVN". Das ist womöglich etwas besser für Anfänger geeignet als git. Es gibt zwar auch "TortoiseGit", aber das habe ich als Schrott empfunden. Bei git gilt: Entweder richtig (saubere IDE-Integration oder Kommandozeile) oder gar nicht. TortoiseGit habe ich einzig und allein wegen des Diff-Tools installiert.
Auch von mir: git plus VSCode. Von den vielen Befehlen braucht man normalerweise eh nur eine Handvoll. Natürlich geht auch SVN. Aber warum auf ein sterbendes Pferd setzen... Und alle die ich kenne und historisch SVN nutzen müssen, wünschen sich Branches wie in git.
Wühlhase schrieb: > Peter Pan schrieb: > >> Lese ich immer wieder, nur irgendwie konnte mir noch keiner aufzeigen, >> wieso SVN einfacher sein sollte. > > Nichts für ungut, aber es scheint so als hättest du den Unterschied > zwischen git und SVN nicht begriffen. > Bei SVN kannst du dich z.B. nicht zwischen mehreren Branches verirren, > wenn man überhaupt erst einmal weiß was ein Branch (in git) ist. > Und selbst wenn man dann weiß wie das alles in git funktioniert, dann > gibt es immer noch genug Strategien zur Auswahl mit Branches zu > arbeiten. > SVN ist allein in dieser Hinsicht deutlich intuitiver und schneller zu > verstehen. > Peter Pan schrieb: > >> Es ist schlichtweg deutlich umständlicher und heutigen Anforderungen >> nicht mehr gewachsen. > > Nicht alle Anforderungen, die es heute in dem ein oder anderen Projekt > gibt, werden auch vom TS gestellt. > Im Gegenzug darfst du jetzt aber mal erklären, warum SVN umständlicher > sein soll. > Peter Pan schrieb: > >> https://www.atlassian.com/git/tutorials/setting-up-a-repository >> Oder ist ein >> git init >> git add dummedatei.txt >> git commit -m "initiLer commit' >> Wirklich so schwer und kompliziert? > > Einen Fahrschüler wirst du hoffentlich auch nicht in seiner ersten > Fahrstunde sofort ohne Aufsicht auf die Autobahn lassen, nur weil er auf > Anhieb den Motor starten kann. > Git kann ja auch deutlich mehr als nur eine Datei hinzuzufügen, oder? > Ach ja...was machst du mit deiner Änderung jetzt eigentlich? Pushen, > oder Committen? Bei SVN ist das ja einfach, aber selbst in > proffessionellen Programmierteams soll es vorkommen, daß jemand den > Unterschied vergißt. Und das eine bleiben läßt. > Und wenn der TS dann doch einen zentralen Server haben will...wird git > alles andere als intuitiv. Alles was man für einfaches Arbeiten mit git benötigt kann man sich in wenigen Minuten anlesen. SVN benutzt niemand mehr produktiv weil es einfach eine Katastrophe in der Bedienung ist. Es gibt sture alte Hasen die daran festhalten, aber in der Realität ist es umständlich und Müll. Allein schon dein Argument mit dem Speicherplatz ist lächerlich. Hast du eine 256MB Festplatte oder was? Willst du etwa binary einchecken? Git speichert die Änderungen in Form von Patches. Effizienter wird es bei Quelltext kaum. Was soll eine Working Copy sein? DAS musst du einem Einsteiger erst einmal erklären. SVN hat viele Eigenheiten die du als toll anpreist die eigentlich scheisse sind. SVN ist etwas für Eigenbrötler, für Leute die in einem Team arbeiten ist das nix, genauso wenig für Einsteiger. Er will eine lokale Versionsverwaltung. Jetzt kommst du mit einem System mit Working Copy und bla an. Und was soll so schlimm an Branches sein? Ich glaube DU hast git nicht verstanden.
Wühlhase schrieb: > Ach ja...was machst du mit deiner Änderung jetzt eigentlich? Pushen, > oder Committen? Bei SVN ist das ja einfach, aber selbst in > proffessionellen Programmierteams soll es vorkommen, daß jemand den > Unterschied vergißt. Und das eine bleiben läßt. Wenn du zu doof bist um 5 Minuten Doku zu lesen und dennoch zu stolz bist dir die zwei Befehle auf einen Zettel am Monitor zu schreiben hättest du von mir schon längst die Kündigung erhalten. Oder kannst du etwa kein Englisch? Die Befehle sind quasi selbsterklärend. Das ist ja so ziemlich das dümmste Argument welches ich je gelesen habe. Dein Problem ist das, dass du noch immer wie in SVN arbeiten möchtest, aber dieser Ansatz ist vollkommener Blödsinn. Wer git ohne Pull Requests und Branches und ohne CI nutzt weiß gar nicht, wie entspannt das ist als Entwickler. Es liest sich so, als ob git commit für dich nur ein Strg+s nach dem Tagwerk ist und man direkt pushen muss. Könnte es vielleicht einen Grund haben, wieso das zwei Befehle sind? So arbeitet man halt nicht. Man baut seine Änderungen so auf, dass Commits möglichst minimale Änderungen darstellen welche einfach nachvollziehbar sind und stets baubar sind. Dabei wechselt man zuvor auf einen Feature Branch und pusht zwar auch nach jedem Commit, aber das nur damit man vom CI Feedback hinsichtlich Tests usw. bekommt. Zwingend erforderlich ist es eigentlich nicht. Am Ende stellt man dann einen PR welcher entsprechend von anderen Entwicklern ggf. genehmigt wird, nebenbei werden diese dadurch über die Änderungen informiert. Das ist bestimmt wieder etwas woran du dich als alter SVN Hase störst. Wie können die es wagen den heiligen Code von Mr. Perfect welcher sich nicht einmal zwei Wörter merken kann rewieven zu wollen?
Neben Git (git) und Subversion (svn) wäre noch Mercurial (hg) eine Alternative. Die Basisfunktionen sind in allen drei Programmen sehr ähnlich, teilweise ist sogar die Syntax der Kommandos gleich. Beispiele:
1 | [git|svn|hg] add <Dateiliste> |
2 | [git|svn|hg] commit -m 'Beschreibung der Änderungen' |
Deswegen ist für den Anfang ziemlich egal, welches der drei Programme man wählt. Wenn man aber irgendwann fortgeschrittenere Features nutzen möchte, ist man mit git und hg besser bedient, weil sie mehr zu bieten haben als svn. Für git spricht zudem die sehr große (aktive) Community. Evtl. wäre noch Darcs eine Option. Die zugrunde liegende Philosophie ist eine andere als in git, hg und svn und in den wesentlichen Punkten ganz gut im deutschen Wikipedia-Artikel beschrieben. Umsteiger von git & Co müssen sich daran aber erst ein wenig gewöhnen. Darcs ist sehr benutzerfreundlich, was auch den Einstieg erleichtert. So werden bspw. bei fehlerhafter Bedienung nicht nur sehr ausführliche Fehlermeldungen ausgegeben, sondern auch Erläuterungen geliefert, wie es möglicherweise zu dem Fehler kommen konnte und was getan werden muss, um ihn zu vermeiden. Sind für eine bestimmte Operation die Angaben des Benutzers unvollständig, werden diese interaktiv nachgefragt. Leider ist die Community von Darcs nicht sehr groß, so dass man in Problemfällen weniger Support im Netz findet als bspw. bei Git.
:
Bearbeitet durch Moderator
Für jemanden, der bisher keine Versionsverwaltung benutzt hat (warum sonst sollte er die Frage stellen) ist SVN konzeptionell einfacher. Mit TortoiseSVN gibt es eine funktionelle Oberfläche, die anfängertauglich ist. Sobald es um Arbeit im Team geht, ist natürlich git das Mittel der Wahl. Oder umgekehrt: Falls mal jemand anderes die Pythonskripte braucht, wird er git als den Standardweg empfinden, SVN möglicherweise als altbacken, alles andere als exotisch.
Thilo R. schrieb: > Für jemanden, der bisher keine Versionsverwaltung benutzt hat (warum > sonst sollte er die Frage stellen) ist SVN konzeptionell einfacher. https://sdq.kastel.kit.edu/wiki/Versionsverwaltung_mit_Subversion_(SVN) DAS soll einfacher sein?
Moin, um mal einzelen Scripte zu versionieren fand ich die automatische Keyword Expansion von CVS immer sehr hilfreich. Egal wo man sein Script hin kopiert hat, man kann nachvollziehen welche Version es ist. Gibt es so etwas eigentlich bei irgendeinem der aktuellen Systeme? Git hat es ja meines Wissens nach nicht, dafür kann ich ein lokales Repo einfacher anlegen als mit CVS, was einen server-Part erfordert. Git macht bei verteilter Entwicklung von vielen voneinander anhängigen Quellcode-Dateien wie z.B. einem Linux Kernel Sinn. Für jemanden, der selbst ein paar Scripte versioniert ist das eher nix. Gruß, Harri
Harald S. schrieb: > Moin, > > Git macht bei verteilter Entwicklung von vielen voneinander anhängigen > Quellcode-Dateien wie z.B. einem Linux Kernel Sinn. Für jemanden, der > selbst ein paar Scripte versioniert ist das eher nix. Selbst ein paar eigene Rezepte kann man mit git einfach versionieren. Die einfache Diff Funktion in VSC möchte ich nicht mehr missen. Server kann man benutzen, muss man aber nicht. Für Code macht es aber schon Sinn den auf einem zentralen Server abzulegen. Mit Gitea gibt es dafür ja auch eine einfache Variante. Man sollte git sogar vor dem Programmieren lernen um garnicht erst ins Chaos mit zippen und unkontrolliertem rumbrobieren zu kommen.
:
Bearbeitet durch User
A. S. schrieb: > Du installierst > Tortoise/SVN auf Deinem Rechner, nimmst einen leeren Ordner und > eröffnest dort mit der rechten Maustaste ein neues Repository. Ohne > Webgedöns, Server oder was weiß ich. Innerhalb von Minuten kannst Du > lokal loslegen, notfalls ohne Internet auf einem Uraltrechner. Ist bei git auch nicht komplizierter. Im Gegenteil, mit z.B. Sourcetree gibts auch Tools die im gegensatz zu TortoiseSVN/TortoiseGit auch zeitgemäß sind. Frank K. schrieb: > Das ist ja nur der Anfang. > > Szenario: Ich habe einen Haufen versionierter Dateien mit lokalen > Änderungen, die ich auf einem Repository auf einem Server einchecken > will. > > svn: svn ci -m "text" > > git: git add -all && git commit -m "text" && git push Dann nimm halt einen grafischen Client, wir leben ja nicht in den 90ern. Frank K. schrieb: > Bei SVN habe ich kein lokales Repository (außer ich lege mir eines an), > sondern nur meine Working Copy. Bei git comitte ich immer erstmal ins > lokale Repo (das dann mindestens so viel Platz wie meine Working Copy > braucht) und muss das dann nochmal extra pushen. Klassischer Fall von "Anforderungen nicht gelesen": er will rein offline arbeiten, er braucht (noch) kein remote Repo. Wühlhase schrieb: > Bei SVN kannst du dich z.B. nicht zwischen mehreren Branches verirren, > wenn man überhaupt erst einmal weiß was ein Branch (in git) ist. > Und selbst wenn man dann weiß wie das alles in git funktioniert, dann > gibt es immer noch genug Strategien zur Auswahl mit Branches zu > arbeiten. > > SVN ist allein in dieser Hinsicht deutlich intuitiver und schneller zu > verstehen. Du bist aber ein lustiges Kerlchen, ich kann sowohl bei SVN als auch bei git entweder mit oder ohne Branches arbeiten. Was faselst du da also daher? A. S. schrieb: > Der Vorteil bei Tortoise (SVN auf einem Windows PC): Du installierst > Tortoise/SVN auf Deinem Rechner, nimmst einen leeren Ordner und > eröffnest dort mit der rechten Maustaste ein neues Repository. Ohne > Webgedöns, Server oder was weiß ich. Innerhalb von Minuten kannst Du > lokal loslegen, notfalls ohne Internet auf einem Uraltrechner. Gratuliere, genau so wie bei git. :) Nur dass es halt zeitgemäße Tools gibt dafür, die nicht aus den 90ern stammen. Wühlhase schrieb: > Nicht alle Anforderungen, die es heute in dem ein oder anderen Projekt > gibt, werden auch vom TS gestellt. Natürlich nicht, SVN hat halt einfach keinerlei Vorteile, alles was SVN kann kann git auch, und das was git mehr kann musst du nicht nutzen solang du nicht willst. Wühlhase schrieb: > Im Gegenzug darfst du jetzt aber mal erklären, warum SVN umständlicher > sein soll. Keine zeitgemäße grafische Oberfläche, schlechtere Integration in alle möglichen Tools, weils halt keiner mehr verwendet P. S. schrieb: > Für SVN spricht aber das sehr gute Windows-Frontend "TortoiseSVN". Das > ist womöglich etwas besser für Anfänger geeignet als git. Es gibt zwar > auch "TortoiseGit", aber das habe ich als Schrott empfunden. Bei git > gilt: Entweder richtig (saubere IDE-Integration oder Kommandozeile) oder > gar nicht. TortoiseGit habe ich einzig und allein wegen des Diff-Tools > installiert. TortoiseGIT ist Krebs, es versucht halt eine SVN-Gui aus den frühen 2000ern mit git zu kombinieren, was in katastrophaler Bedienbarkeit endet. Nimm halt Sourcetree, GitKraken, VSCode oder deinen Lieblingseditor mit git-Integration, man hat ja bei git eh die Wahl zwischen drölfzig grafischen Frontends. Wühlhase schrieb: > Ach ja...was machst du mit deiner Änderung jetzt eigentlich? Pushen, > oder Committen? Bei SVN ist das ja einfach, aber selbst in > proffessionellen Programmierteams soll es vorkommen, daß jemand den > Unterschied vergißt. Und das eine bleiben läßt. Wenn dich sowas schon überfordert solltest du deine Karriereentscheidung überdenken. Thilo R. schrieb: > ist SVN konzeptionell einfacher Inwiefern? Thilo R. schrieb: > Mit > TortoiseSVN gibt es eine funktionelle Oberfläche, die anfängertauglich > ist Für git gibts ca. drölfzig Oberflächen zur freien Wahl, also kein Argument. Für Anfänger unter Windows bietet sich GitHub Desktop (funktioniert auch ohne GitHub), GitKraken, Sourcetree oder die Integration in fast jeden Codeeditor an. Harald S. schrieb: > Für jemanden, der > selbst ein paar Scripte versioniert ist das eher nix. Weil?
Peter Pan schrieb: > Wühlhase schrieb: >[..] > Alles was man für einfaches Arbeiten mit git benötigt kann man sich in > wenigen Minuten anlesen. Wie gesagt, es ist unwahrscheinlich daß du git benutzt, du würdest diesen Unsinn sonst nicht absondern. Oder schlimmer: Du gehörst du denen, die nicht wissen was sie tun, deine Unflätigkeiten sprechen dafür. Und so oder so sollte man sein Werkzeug halbwegs kennen, und bei git mußt du erstmal wissen was du nutzen solltest und was nicht. Ich kann dir jedenfalls sagen, daß Rene Preißel und Bjorn Stachmann ihr git-Buch (das ich übrigens sehr empfehlen kann) nicht mit Belanglosigkeiten gefüllt haben und sie nach eigener Aussage trotzdem nicht auf alles eingehen konnten. Höre auf diesen Unsinn zu verbreiten, daß man in ein paar Minuten zum git-Profi wird. Peter Pan schrieb: > SVN benutzt niemand mehr produktiv weil es einfach eine Katastrophe in > der Bedienung ist. ...was schlicht nicht stimmt. Ich kenne zwar nur TortoiseSVN, das aber funktioniert sehr gut und einfach. Kann jeder selber ausprobieren. Peter Pan schrieb: > Es gibt sture alte Hasen die daran festhalten, aber in der Realität ist > es umständlich und Müll. Behauptest du nun zum zweiten mal, ohne mit einem einzigen Argument zu kommen. Davon wird es nicht wahrer. Peter Pan schrieb: > Allein schon dein Argument mit dem Speicherplatz ist lächerlich. Hast du > eine 256MB Festplatte oder was? Willst du etwa binary einchecken? Git > speichert die Änderungen in Form von Patches. Effizienter wird es bei > Quelltext kaum. Und nun wirds komplett lächerlich, hier hat niemand den Speicherbedarf als Argument angeführt, außer du. Solche Rhetoriktricks funktionieren vielleicht in mündlichen Diskussionen, aber nicht in schriftlichen. Peter Pan schrieb: > [..] hättest du von mir schon längst die Kündigung erhalten [..] Haha, als ob du Brausepaul jemals in der Position wärst über meine Einstellung oder gar Kündigung auch nur mitzreden.
Wühlhase schrieb: > Ich kann dir jedenfalls sagen, daß Rene Preißel und Bjorn Stachmann ihr > git-Buch (das ich übrigens sehr empfehlen kann) nicht mit > Belanglosigkeiten gefüllt haben und sie nach eigener Aussage trotzdem > nicht auf alles eingehen konnten. Höre auf diesen Unsinn zu verbreiten, > daß man in ein paar Minuten zum git-Profi wird. Dass man in ein paar Minuten zum Profi wird habe ich nie behauptet, das kam von dir, da sind wir wieder bei den rhetorischen Tricks, was? Es ging um die grundlegenden Befehle um damit solo zu arbeiten und das ist schlichtweg nicht komplex mit git. Hast du denn die von mir verlinkte Anleitung bei Atlassin gelesen? Es erwartet keiner von einem Einsteiger dass er direkt Cherry Picking und mehr nutzt, aber für die lokale Versionierung braucht er das eh (zumindest anfangs) nicht. Allein schon deine "ich habe ein git Buch gelesen" Haltung zeigt, dass du mehr Angsthase statt Wühlhase bist. Was hindert dich daran, diese paar Befehle aus den Tutorial einmal durchzuspielen? Details kann man sich danach noch immer aneignen, insbesondere wenn man mehr Funktionalität benötigt. Aber lieber erst 2000 Stunden Literatur studieren und ängstlich sein anstatt einfach einmal ein Tutorial durchzuspielen um mit dem Tool vertraut zu werden. Du kannst 20 Bücher über Schwimmen lesen. Du wirst danach dennoch nicht schwimmen können, die Übung macht es. Irgendwann muss man einfach ins kalte Wasser springen. Genauso verhält es sich mit Tools. Erst du die Benutzung erlernt man deren Verwendung. Ich mein, was könnte im schlimmsten Fall schon schiefgehen? Ach richtig, du könntest dein Testrepo mit Pseudo Daten verlieren. Wow. Zudem sind Bücher heutzutage so schnell überholt dass diese im Moment des Druckes bereits überholt sind. Wie sicher können wir sein, dass in all deinen Büchern master als Default Branch drinnen steht und nicht der inzwischen per Default gesetzte main?
Ich benutze gerne Fossil. Eine schlanke EXE-Datei, Wiki und Tickets inklusive. https://fossil-scm.org/
Yalu X. schrieb: > Neben Git (git) und Subversion (svn) wäre noch Mercurial (hg) eine > Alternative. Die Basisfunktionen sind in allen drei Programmen sehr > ähnlich, teilweise ist sogar die Syntax der Kommandos gleich. > > Beispiele: > >
1 | > [git|svn|hg] add <Dateiliste> |
2 | > [git|svn|hg] commit -m 'Beschreibung der Änderungen' |
3 | > |
Vorsicht! "svn add" und "git add" sind falsche Freunde, ähnlich wie "bekommen" und "become". Wenn man häufiger mit beiden VCS auf der Kommandozeile arbeitet, passieren einem hin und wieder entsprechende Fehler. "svn add" wird ja nur einmalig verwendet, um SVN eine Datei oder ein Verzeichnis beizubringen, wohingegen "git add" vor jedem Commit und nicht nur einmalig ansteht. Der git-Ansatz (add->commit->push) ist zwar natürlich leistungsfähiger, erfordert aber auch mehr Einzelschritte.
Wühlhase schrieb: > Wie gesagt, es ist unwahrscheinlich daß du git benutzt, du würdest > diesen Unsinn sonst nicht absondern Lustiges Kerlchen. Wühlhase schrieb: > Ich kann dir jedenfalls sagen, daß Rene Preißel und Bjorn Stachmann ihr > git-Buch (das ich übrigens sehr empfehlen kann) nicht mit > Belanglosigkeiten gefüllt haben und sie nach eigener Aussage trotzdem > nicht auf alles eingehen konnten. Für Anfänger komplett irrelevant. Um ein Auto fahren zu können muss ich auch nicht verstehen wie ein Verbrennungsmotor funktioniert. Wühlhase schrieb: > Höre auf diesen Unsinn zu verbreiten, > daß man in ein paar Minuten zum git-Profi wird. Hat keiner getan, hör auf Märchen zu verbreiten. Wühlhase schrieb: > Ich kenne zwar nur TortoiseSVN Warum schreibst du dann über Dinge die du nicht kennst? Wühlhase schrieb: > Behauptest du nun zum zweiten mal, ohne mit einem einzigen Argument zu > kommen. Davon wird es nicht wahrer. Allein die mangelnde Integration in andere Tools macht die Nutzung hinfällig. Wühlhase schrieb: > Haha, als ob du Brausepaul jemals in der Position wärst über meine > Einstellung oder gar Kündigung auch nur mitzreden. Stimmt, Leute die mit der Bedienung eines grafischen Git-Client überfordert sind weil sie in der Tortoise*-Welt der frühen 2000er hängen geblieben sind werden in der Praxis leider sehr oft wegbefördert, damit die anderen Entwickler in Ruhe arbeiten können und nicht von Geschichten aus dem Weltkrieg gelangweilt werden. Egal, das Boomer-Problem erledigt sich eh biologisch. :)
Andreas S. schrieb: > Der git-Ansatz (add->commit->push) ist zwar natürlich leistungsfähiger, > erfordert aber auch mehr Einzelschritte. Lösung: im git-Client "push on commit" anhaken wenn man das wirklich will. Für den TS aber eher irrelevant, er will eine Offline-Versionierung.
Or, endlich mal nen Git vs. SVN-Flamewar! Also SVN mit ner fast 3-stelligen Anzahl an Externals muss nicht so geil sein, wie die SVN-Befürworter das gerne meinen würden... auch wenn der SVN-Server mal die Haxen hochreißt, biste potenziell dezentral verwaltet besser aufgestellt. Allerdings braucht git auch die ein oder andere Extrawurst z.B. beim Umgang mit Binaries. Also bei der Frage: wohin mit kompiliertem Zeug oder Bildern/Dokumenten - gehört grundsätzlich zwar auch nicht ins SVN, wird wohl aber auch manchmal gemacht. Oder obs nun Subtrees oder Submodule sein sollen (oder gar nix, alles in einem)... Ohne Lernkurve gehts bei beidem nicht - ein Branch im SVN passiert halt auf dem Server, beim Git lokal. Beim Git haste da ein Repo, bei SVN musste switchen oder nen zweiten Checkout machen. Also rum wie num, tendenziell bin ich eher für Git, weils bessere Perspektiven für die Arbeit damit bietet.
Thilo R. schrieb: > Für jemanden, der bisher keine Versionsverwaltung benutzt hat (warum > sonst sollte er die Frage stellen) ist SVN konzeptionell einfacher. Das kann ich nicht so richtig nachvollziehen. An welcher Stelle ist für einen Anfänger, der ja nur einen kleinen Bruchteil der Features von Git oder SVN benötigt, SVN einfacher als Git? Pater hat oben die ersten Schritte für das Anlegen und Befüllen eines Repositorys in Git gezeigt: Peter Pan schrieb: > git init > git add dummedatei.txt > git commit -m "initiLer commit' Geht das mit SVN einfacher? Um zu sehen, was man gemacht hat, braucht man noch die Unterkommandos log, status und diff. Wichtig sind noch mv und rm für das Umbenennen und Löschen von Dateien sowie checkout für die Wiederherstellung alter Versionen. Damit kommt man am Anfang schon ziemlich weit. Welche Vereinfachungen bietet SVN hierfür an? Alles weitere wie bspw. branch, merge usw. braucht man nicht sofort zu Beginn, weswegen man sich das dafür benötigte Wissen nach und nach in aller Ruhe aneignen kann. Da der TE offensichtlich alleine und nicht in einer Gruppe arbeitet, ist erst einmal kein Verständnis von lokalen und Remote-Repositories vonnöten, womit auch Unterkommandos wie push, pull und fetch unwichtig sind. Andreas S. schrieb: > Vorsicht! "svn add" und "git add" sind falsche Freunde, ähnlich wie > "bekommen" und "become". Wenn man häufiger mit beiden VCS auf der > Kommandozeile arbeitet, passieren einem hin und wieder entsprechende > Fehler. "svn add" wird ja nur einmalig verwendet, um SVN eine Datei oder > ein Verzeichnis beizubringen, wohingegen "git add" vor jedem Commit und > nicht nur einmalig ansteht. Ja, stimmt, das ist nicht exakt dasselbe. Sehr ähnlich wird das Vorgehen aber, wenn man git commit mit mit einer Liste der zu committenden Dateien (wie auch in SVN möglich) bzw. der Option -a (entspricht in etwa svn commit ohne Dateiliste) benutzt. Dann ist ein explizites add wie in SVN nur einmal beim Neuanlegen von Dateien erforderlich. Das mehrschrittige Vorgehen in Git hat zwar Vorteile, erzwungen wird es aber nicht.
vnnn schrieb: > Natürlich nicht, SVN hat halt einfach keinerlei Vorteile, alles was SVN > kann kann git auch, und das was git mehr kann musst du nicht nutzen > solang du nicht willst. Das ist so nicht ganz korrekt. 1. Prinzipbedingt stellt ein verteiltes VCS wie git keine Lamport-Uhr dar. Da bei Git auch nicht bekannt ist, welche Akteure in welchen geclonten Repositories einchecken, kann prinzipbedingt auch keine Vektoruhr konstruiert werden. Commits werden zwar eindeutig über ihre Hashwerte erfasst, aber die Hashwerte lassen sich nur auf Gleichheit prüfen, aber nicht im Sinne einer Kausalkette sortieren. Wenn man SVN mit einem einzigen großen Repository betreibt, was auch aus anderen Gründen sinnvoll ist, stellt dies eine exzellente Lamport-Uhr dar. Durch die erzeugte Revisionsnummer können zwei Checkings hinsichtlich ihrer zeitlichen Reihenfolge eindeutig angeordnet werden. Somit kann man auch "kleine" Zwischenstände an Dritte geben, ohne diese zuvor mit einem Tag o.ä. versehen zu müssen. Ein Außenstehender kann auch ohne Zugriff auf das/ein Repository erkennen, welches der ältere oder neuere Versionstand ist. Git sieht hingegen keinen entsprechenden Automatismus vor, sondern die (ggf. mehrdeutige) Vergabe entsprechender Tags oder sonstiger Versionskennzeichnungen muss durch den Eincheckenden erfolgen. Natürlich hat dies für "richtige" Lieferungen auch Vorteile, führt aber eben auch zu einer "Tag-Flut". 2. Prinzipbedingt ermöglicht Git keine fein granulare *Lese*-Rechtevergabe (pull, fetch, fork, ...) für den Zugriff auf ein Repository. Insbesondere lässt sich nicht nachträglich für einen neuen Akteur der Zugriff auf nur einen Teilbereich eines Repositories einrichten, sondern nur auf das ganze Repository. Wenn also später jemand mit eingeschränkten Zugriffsrechten hinzukommen soll, muss also das Repository in separate zerlegt werden. Bei Subversion sind die nutzerspezifischen Zugriffsrechte jedoch serverseitig auch für nur bestimmte Teilbäume eines Repositories konfigurierbar und beeinflussen vor allem nicht die schon bestehenden Nutzer und Rechte. Bei Git muss man folglich schon bei der initialen Planung der Verzeichnis- und daraus folgend Repositorystruktur berücksichtigen, welche zusätzlichen Akteure ggf. Jahre später in einem deutlich gewachsenen Projekt hinzukommen können. Dies ist jedoch ziemlich unmöglich. Mittlerweile unterstützt Git immerhin die Einschränkung von Schreiboperationen auf bestimmte Branches. Damit sind aber Versionsbranches und nicht Verzeichnisbäume innerhalb bestehender Repositories gemeint. Das ganze hat nicht nur technische, sondern vor allem auch vertragliche Aspekte, gerade dann, wenn z.B. bestimmte Arbeiten durch externe Mitarbeiter erledigt werden sollen. > Keine zeitgemäße grafische Oberfläche, schlechtere Integration in alle > möglichen Tools, weils halt keiner mehr verwendet Der Trend geht hier zwar ganz klar in Richtung Git, aber es gibt auch heute noch etliche aktuelle Entwicklungsumgebungen, die eben (noch) auf anderen VCS basieren. Ein Beispiel hierfür ist Wago e!Cockpit, welches die einzige für aktuelle Wago SPS geeignete Entwicklungsumgebung ist. Für das darunter befindliche Codesys gibt es zwar schon seit längerem eine Git-Integration, aber Wago hat sie nicht übernommen. Dummerweise werden die Projektquelltexte nicht in ggf. extern versionierbaren Quelltextdateien gespeichert, sondern die gesamte Arbeitskopie befindet sich in einem proprietären "Dateiklumpen", ähh in einer "Datenbank". Interessanterweise sieht die SVN-Repositorystruktur gänzlich anders aus; dort findet man das ganze Projekt dann schon fein säuberlich aufgedröselt in einzelne Quelltexte und Konfigurationsdateien. Ich gehe davon aus, dass Wago den Git-Konnektor zwar auch irgendwann übernehmen und einbauen wird, aber Stand heute ist das nicht der Fall. Meine ganzen Ausführungen sollen Git nicht generell schlechtreden, denn es besitzt natürlich auch unzählige Vorteile gegenüber SVN. Es ging ausschließlich um die nachweislich falsche Behauptung, Git erfülle sämtliche Leistungsmerkmale von SVN. In meinem Unternehmen nutzen wir beides, d.h. historisch bedingt überwiegend SVN (auch weil Altium Designer <=17 ausschlieslich CVS und SVN, aber kein Git unterstützt), aber auch Git in Verbindung mit einem Gitea-Server.
Also wenn die Linux mit git entwickeln und da x-Leute verteilt dran arbeiten und es offensichtlich funktioniert...ist das dann nicht alles etwas akademischer Natur diese Art von "Einschränkungen"?
Andreas S. schrieb: > Prinzipbedingt ermöglicht Git keine fein granulare Lese-Rechtevergabe > (pull, fetch, fork, ...) für den Zugriff auf ein Repository. > Insbesondere lässt sich nicht nachträglich für einen neuen Akteur der > Zugriff auf nur einen Teilbereich eines Repositories einrichten, sondern > nur auf das ganze Repository. Fork kannst ja effektiv nicht verhindern. Im gewerblichen Umfeld ist es eigentlich nur wichtig nicht einfach auf master/develop/stable/release pushen zu können und das kann man eigentlich bei den meisten Servern erzwingen. Bitbucket usw. kann das. Teilbereiche finde ich nicht sonderlich relevant hinsichtlich Einschränkung, entweder gehört es eh in ein Submodul oder deine Anwendung hat mit hoher Wahrscheinlichkeit Probleme hinsichtlich der Architektur. Ich habe so gigantische SVN/git Repos gesehen und da muss ich sagen da sind Grundlagen des Dependency Management und Wartbarkeit nicht verstanden worden. In einem habe ich 9 (!) Mal unterschiedliche Versionen einer einzigen Bibliothek finden dürfen. Alles eingecheckte Kopien an unterschiedlichen Stellen. Alle Versionen veraltet und inkl. Sicherheitslücken. Da waren übrigens SVN Hasen am Werk welche das Problem nicht einmal verstanden haben nachdem man es ihnen erklärt hat, das wurde mehr so zur Kenntnis genommen von wegen man habe das schon immer so gemacht und es funktioniere ja.
Ich sehe nicht, welchen Vorteil der Lamport-Uhr oder Vektoruhr Blödsinn bringen sollte. Wenn ich in git einen Commit mache, ist da drin eine Referenz die genau angibt auf welchen commits das basiert. Und ein Zeitstempel kommt auch rein, das Wann weiss ich also auch. Ich habe also eine exakte und einwandfreie Historie aller Änderungen und wie die zusammenhängen, die ich auch beliebig durchsuchen kann. Bei Konflikten weiss ich auch, welches der letzte gemeinsame Stand / Commit war. Welchen praktischen Vorteil würde mir der Lamport-Uhr oder der Vektoruhr Blödsinn bringen? Ich sehe keinen.
Peter Pan schrieb: > Im gewerblichen Umfeld ist es eigentlich nur wichtig nicht einfach auf > master/develop/stable/release pushen zu können und das kann man > eigentlich bei den meisten Servern erzwingen. Bitbucket usw. kann das. Eigentlich auf allen. Selbst ohne Server / Webfrontend. Es gibt dort ja immer ein bare Repo, und dort kann man Hooks hinterlegen. Da kann man dann alles mögliche kontrollieren & erzwingen.
Peter Pan schrieb: > Im gewerblichen Umfeld ist es eigentlich nur wichtig nicht einfach auf > master/develop/stable/release pushen zu können und das kann man > eigentlich bei den meisten Servern erzwingen. Bitbucket usw. kann das. Im gewerblichen Umfeld ist es vor allem wichtig, die Vertragsbeziehungen mit Kunden und Lieferanten im Blick zu haben. Wenn mit einem Kunden vereinbart wurde, dass ausschließlich die mit einem bestimmten Projekt oder Teilprojekt betrauten Mitarbeiter Zugriff auf die Daten haben dürfen, hat das unmittelbare Auswirkungen auf Repositories, Netzwerklaufwerke, usw.. Und wenn ein externer Mitarbeiter eine bestimmte Teilaufgabe erledigen soll, gilt das um so mehr. > Teilbereiche finde ich nicht sonderlich relevant hinsichtlich > Einschränkung, entweder gehört es eh in ein Submodul oder deine > Anwendung hat mit hoher Wahrscheinlichkeit Probleme hinsichtlich der > Architektur. Selbst wenn man im Laufe der Zeit feststellt, dass eine Neuordnung der Module, Repositories o.ä. sinnvoll ist und man diese auch durchführt, muss man auch die Zugriffsrechte auf historische Daten berücksichtigen. > Ich habe so gigantische SVN/git Repos gesehen und da muss ich sagen da > sind Grundlagen des Dependency Management und Wartbarkeit nicht > verstanden worden. In einem habe ich 9 (!) Mal unterschiedliche > Versionen einer einzigen Bibliothek finden dürfen. Alles eingecheckte > Kopien an unterschiedlichen Stellen. Alle Versionen veraltet und inkl. > Sicherheitslücken. Da waren übrigens SVN Hasen am Werk welche das > Problem nicht einmal verstanden haben nachdem man es ihnen erklärt hat, > das wurde mehr so zur Kenntnis genommen von wegen man habe das schon > immer so gemacht und es funktioniere ja. Aha, das ist also die Schuld von SVN. Interessant. Mit Git wäre so etwas natürlich niemals passiert. Ich nutze z.B. für Bibliotheken (insbesondere Bauteilebibliotheken für Altium Designer), die in verschiedenen Projekten immer im jeweils aktuellen Stand verwendet werden sollen, svn:externals. Im jeweiligen Entwicklungszweig zeigen sie auf die HEAD-Revision, in eingefrorenen Ständen, d.h. im tags-Baum, wird natürlich die Revision explizit gesetzt. Oder liegt es vielleicht doch an Deiner eingeschränkten Sichtweise? Die "reine Lehre" besagt zwar, dass generierte Artefakte (z.B. Kompilate) nicht im VCS eingecheckt werden sollen. Dennoch erweist sich dies häufig als sinnvoller Weg, da man hierdurch sicherstellt, dass die Artefakte nicht verloren gehen bzw. der Zusammenhang mit den zugehörigen Quellen sofort sichtbar ist. Natürlich muss sichergestellt werden, dass diese Artefakte entfernt werden, wenn man einen neuen Build durchführt. Es kann je nach Situation auch richtig sein, dass veraltete und ggf. fehlerhafte Stände weiterhin verwendet werden. Da sind die interessanten Fragen: 1. Wurde der alte Stand von einem Kunden abgenommen und womöglich für einen bestimmten Zweck "zertifiziert"? 2. Gibt es einen Geschäftszweck, der die Pflege des alten Standes erfordert? 3. Bezahlt ein Kunde die entsprechende Pflege und Fehlerkorrekturen? Mit "Kunde" sind nicht nur unternehmensfremde Geschäftspartner gemeint, sondern es gibt natürlich auch interne Kunden. Kein interner Auftrag, keine Leistung.
Andreas S. schrieb: > Dennoch erweist sich dies häufig als sinnvoller Weg, da man hierdurch > sicherstellt, dass die Artefakte nicht verloren gehen bzw. der > Zusammenhang mit den zugehörigen Quellen sofort sichtbar ist. Dann ist dein Build nicht reproduzierbar und damit in meinen Augen nicht stabil. Würde das auch als nicht debuggbar betrachten da nicht deterministisch. Andreas S. schrieb: > Aha, das ist also die Schuld von SVN. Interessant. Mit Git wäre so etwas > natürlich niemals passiert. Nö, kann mit git natürlich genauso passieren. Nur sind die Verfechter dieser unzähligen Kopien ebenfalls SVN Verfechter weil das angeblich einfacher sei. Und zertifiziert sind da keine Bibliotheken und nix, es hat schlichtweg keinen Grund. Daher ist es ja so absurd. Der Kunde bekommt davon nix, die Anwendung läuft auf einem embedded Gerät. Die nehmen sogar den Linux Kernel und checken den in SVN ein. Und die Buildartefakte genauso.
Wenn ich eine unabhängig entwickelte Lib von mir in meinem Projekt verwende, nehme ich in Git ein Submodul. Aber als Repo geb ich dann "." das lokale Repo, an. Ich schieb dass dann da in einen eigenen Branch. Zum updaten pull ich den halt nochmal vom upstream remote, und update dann das Submodul. Ist leider etwas umständlich, aber geht einwandfrei. Der Vorteil das so zu machen, ist, dass man eine Kopie von der Lib mit ihrer ganzen Historie hat, auch wenn das upstream Repo mal verschwinden sollte.
Merten schrieb: > Gibt es eine einfache zu handhabende Versionsverwaltung für den PC > (Windows)? > Ich möchte gerne Pythonskripte offline verwalten. Den Dateiversionsverlauf in Windows aktivieren. Das Ziellaufwerk kann ein NAS sein. Wenn du den dortigen Ordner FileHistory auf deinem PC wieder einbindest dann kannst du dort direkt auf die Abfolge aller Versionen der Skripte zugreifen und vergleichen. LG, Sebastian
Sebastian schrieb: > Den Dateiversionsverlauf in Windows aktivieren. Ich muss ehrlich zugeben dass das eine schön simple Lösung ist. Besser als nichts allemal und bietet eine weitere Sicherheit, selbst wenn man zusätzlich git verwendet. Und das nur mit Bordmitteln. Ich würde zwar noch ein automatisches Backup mittels z.B. Duplicati hinzufügen, aber so ist das echt nicht verkehrt...
Peter Pan schrieb: > Dann ist dein Build nicht reproduzierbar und damit in meinen Augen nicht > stabil. Wenn man die Artefakte nicht versioniert, kann man nicht überprüfen, ob ein neuer Build dasselbe Ergebnis (abgesehen von Zeitstempeln o.ä.) liefert. Und wenn man die Artefakte außerhalb des VCS speichert, muss man immer einen Bezug zwischen diesen Artefakten und dem Quellcodestand herstellen. Versioniert man jedoch die Artefakte und stellt sicher, dass es einen Mechanismus gibt, sie vor einem erneuten Build aus den Verzeichnissen zu löschen (z.B. mittels "make clean"), sieht man nach dem Build sofort anhand des VCS-Status, welche Dateien mit anderem Inhalt neu generiert wurden. Natürlich wäre dies auch möglich mit einem separaten Diff-Programm, welches auf die generierten Verzeichnisbäume losgelassen wird. Die generierten Artefakte zu versionieren, bedeutet übrigens nicht zwingend, für jede einzelne Datei ein entsprechendes VCS-Objekt anzulegen, sondern selbstverständlich kann man ja auch (automatisiert) eine ZIP- oder tar-Datei erstellen lassen. > Würde das auch als nicht debuggbar betrachten da nicht > deterministisch. Gerade die archivierten Artefakte erlauben es doch, einen Debugger auf alte Versionsstände loszulassen, ohne vorher einen Build mit einer womöglich nicht mehr genau reproduzierbaren Toolchain durchzuführen. Viele Toolchains gibt es ja mittlerweile auch gar nicht mehr als fixe Installation, sondern sie installieren teilweise auch die jeweils tagesaktuellen neuesten Bestandteile nach. Folglich müsste man zu jedem Fall auch gleich eine VM o.ä. mit exakt der verwendeten Toolchain archivieren. > Nö, kann mit git natürlich genauso passieren. Nur sind die Verfechter > dieser unzähligen Kopien ebenfalls SVN Verfechter weil das angeblich > einfacher sei. Oha, das ist ja eine Argumentation, die in Sachen Bullshit überhaupt nicht mehr zu übertreffen ist. > Und zertifiziert sind da keine Bibliotheken und nix, es > hat schlichtweg keinen Grund. Daher ist es ja so absurd. Wenn es keinen Grund gibt, gibt es vermutlich auch keinen Grund, die Bibliotheken zu aktualisieren. > Der Kunde bekommt davon nix, die Anwendung läuft auf einem > embedded Gerät. Offenbar fehlt Dir jegliches Verständnis für betriebliche Abläufe. > Die nehmen sogar den Linux Kernel und checken den in SVN ein. Ja, natürlich, denn so befindet er sich an derselben Stelle wie die anderen Projektdateien. Wenn es darum geht, die Synchronisation mit einem externen Git-Repository nicht zu verlieren, kann es durchaus sinnvoll sein, einen mehrstufigen Prozess durchzuführen, d.h. mittels lokaler Git-Repositories usw. die Kernel-Quellen zu verwalten und dann eine organisationsinterne "Lieferung" in das andere VCS durchzuführen. Niemand behauptet, dass es sinnvoll wäre, so etwas heutzutage "auf der grünen Wiese" neu aufzusetzen. Bei bestehenden Projektumgebungen muss man aber ggf. zu solchen Maßnahmen greifen. Es kann aber auch noch andere, durchaus unfreiwillige Gründe geben. In Organisationen mit streng zertifizierten Entwicklungsprozessen dauert es häufig Jahre oder Jahrzehnte, bis ein etabliertes Werkzeug ersetzt werden kann. Ggf. müssen auch noch Dritte, z.B. Auftraggeber, Zulassungsbehörden, Zertifizierungsstellen jeder noch so kleinen Änderung zustimmen; so etwas kann locker etliche Millionen Euro kosten. Und bis dahin müssen sich die Entwickler eben mit den vorhandenen Werkzeugen behelfen. > Und die Buildartefakte genauso. Wenn das richtig gehandhabt wird, ist das auch völlig in Ordnung bzw. sogar notwendig. Natürlich kann man an dieser Stelle auch viel falsch machen.
Andreas S. schrieb: > Und wenn man die Artefakte außerhalb des VCS speichert, muss > man immer einen Bezug zwischen diesen Artefakten und dem Quellcodestand > herstellen. Genau das ist Stand der Technik. Stell dir vor, mein CI-Server kann sogar zu jedem Quellcodestand mehrere Builddurchläufe ablegen wenn ich herausfinden will ob nach einem Rebuild das gleiche raus kommt. Andreas S. schrieb: > Versioniert man jedoch die Artefakte Genau das ist Bullshit. Wie passt überhaupt ein Buildserver in dein komisches Konzept? Ich will ja eine Codeänderung comitten/pushen und der Server liefert mir dann ein paar Minuten später das Binary. Andreas S. schrieb: > ohne vorher einen Build mit einer > womöglich nicht mehr genau reproduzierbaren Toolchain durchzuführen. Genau deshalb macht man sowas auch reproduzierbar. Hat ja einen Grund, warum die halbe Welt nur am CI-Server buildet. Andreas S. schrieb: > Viele Toolchains gibt es ja mittlerweile auch gar nicht mehr als fixe > Installation, sondern sie installieren teilweise auch die jeweils > tagesaktuellen neuesten Bestandteile nach. Welche wäre das, die das ungefragt macht? Nur damit ich nicht auf die Idee komm sowas zu nutzen. Aber wenn irgndeiner der 5 Entwickler was auf seinem Rechner (mit unbekanntem Zustand) lokal baut und dann eincheckt ist das reproduzierbar, ja? Andreas S. schrieb: > Offenbar fehlt Dir jegliches Verständnis für betriebliche Abläufe. Lustig, das von jemandem zu lesen der CI-Builds vermutlich nicht kennt. Andreas S. schrieb: > Folglich müsste man zu jedem > Fall auch gleich eine VM o.ä. mit exakt der verwendeten Toolchain > archivieren. Genau, und zu deinen lokal gebauten und eingecheckten Artefakten legst du dann jedes Mal einen Snapshot deines PCs ab, oder wie? Andreas S. schrieb: > Wenn das richtig gehandhabt wird, ist das auch völlig in Ordnung bzw. > sogar notwendig. Es ist immer noch vollkommener Bullshit von jemandem der von moderner Softwareentwicklung und reproduzierbaren Builds keine Ahnung hat. Alleine "reproduzierbar" und "5 Entwickler checken ihre lokal genbauten Artefakte ein" ist ja ein absurder Widerspruch in sich. Und die Zertifizierungsstelle verhindert den Wechsel auf ein modernes Versionierungssystem, sieht gleichzeitig aber zu wie du irgendwelche schwindligen selbstgestricken Workarounds bastelst. Alles klar. Du hast ja sowas von keine Ahnung von Zertifizierungen.
Peter Pan schrieb: > Allein schon deine "ich habe ein git Buch gelesen" Haltung zeigt, dass > du mehr Angsthase statt Wühlhase bist. Was hindert dich daran, diese > paar Befehle aus den Tutorial einmal durchzuspielen? Wozu sollte ich jetzt diese paar Befehle aus dem Tutorial durchspielen? Welchen Erkenntnisgewinn soll mir das Atlassian-Tutorial bringen? Ich benutze SVN tatsächlich deswegen, weil ich es als erstes kennengelernt habe. Nebenbei: Programmieren ist bei nur eine Nebenbaustelle, nix Bedeutendes. Da mir Kollegen aber sagten daß git viel geiler sei, mir aber keiner so recht konkret sagen konnte warum, dann lese ich halt ein gutes Buch darüber. Und selbstverständlich habe ich es damals auch ausprobiert, git hat erst gestern hier auf meinem Laptop ein Update bekommen. Hätte mir git Vorteile gebracht, hätte ich zu git gewechselt, das ist aber nicht der Fall. Ich denke, ich kann die Leistungsfähigkeit von git durchaus beurteilen, auch wenn ich es momentan nicht aktiv benutze. Daß ich hin und wieder mal ein gitrepo klone, würde ich noch nicht als aktive Nutzung ansehen. Daß git Möglichkeiten bietet, die SVN nicht hat, habe ich im Übrigen nirgendwo bestritten. Aber wie gesagt: Wenn man die nicht braucht sollte man sich schon überlegen was man verwendet, einen falschen Befehl in der Konsole einzuhacken ist selten, aber graphische Oberflächen präsentieren einem gleich alle Befehle, da sollte man sich schon etwas darunter vorstellen können was ein Button machen wird. Von SVN später nach git zu wechseln wäre ansonsten ja auch noch eine Option. Yalu X. schrieb: > Thilo R. schrieb: >> Für jemanden, der bisher keine Versionsverwaltung benutzt hat (warum >> sonst sollte er die Frage stellen) ist SVN konzeptionell einfacher. > > Das kann ich nicht so richtig nachvollziehen. > > An welcher Stelle ist für einen Anfänger, der ja nur einen kleinen > Bruchteil der Features von Git oder SVN benötigt, SVN einfacher als Git? Naja, das Prinzip alles auf einen zentralen Server zu schmeißen wäre durchaus genau das, was die meisten wahrscheinlich erstmal erwarten würden, mir war das damals jedenfalls sofort logisch.
Peter Pan schrieb: > SVN benutzt niemand mehr produktiv weil es einfach eine Katastrophe in > der Bedienung ist. > > Es gibt sture alte Hasen die daran festhalten, aber in der Realität ist > es umständlich und Müll. > > Allein schon dein Argument mit dem Speicherplatz ist lächerlich. Hast du > eine 256MB Festplatte oder was? Willst du etwa binary einchecken? Git > speichert die Änderungen in Form von Patches. Effizienter wird es bei > Quelltext kaum. Wir benutzen SVN beinahe ausschließlich, und das produktiv und professionell. Dein Argument stimmt also nicht. Ich finde SVN auch wesentlich intuitiver als Git, aber das ist natürlich subjektiv. Generalisieren ist doch Quark hier. SVN hat genauso seine Daseinsberechtigung wie Git und alle anderen Systeme auch. Das sie sich dir im Falle von SVN nicht erschließt ist völlig OK, das macht SVN aber kein schlechtes System. Und ja, wir checken binary ins Archiv (z.B. die Installer, libraries, Datenblätter, sämtliche Dokumentationen). Für manches gibt es auch keine andere Möglichkeit (frag mal Hardware Entwickler). In den Tags liegen schließlich auch die 'Deliverables', und das sind zumeist binaries. Einer der großen Nachteile von Git finde ich in der Tat das man immer das ganze Repository mit sich rumschleifen muss. Ich möchte das lieber nicht. Meine Präferenz, braucht die Deine natürlich nicht zu sein
Wühlhase schrieb: > Ich denke, ich kann die Leistungsfähigkeit von git durchaus beurteilen, > auch wenn ich es momentan nicht aktiv benutze. Stimmt, du hast ja schon ein Buch drüber gelesen :) Wühlhase schrieb: > Naja, das Prinzip alles auf einen zentralen Server zu schmeißen wäre > durchaus genau das, was die meisten wahrscheinlich erstmal erwarten > würden, mir war das damals jedenfalls sofort logisch. Abgesehen davon dass du das Thema schon wieder verfehlst, weil der TS keinen Server verwenden sondern offline versionieren will: du kannst git auch problemlos mit zentralem Server verwenden, ist auch mit Abstand der häufigste Use Case
Matthi schrieb: > Und ja, wir checken binary ins Archiv (z.B. die Installer, libraries, > Datenblätter, sämtliche Dokumentationen). Für manches gibt es auch keine > andere Möglichkeit (frag mal Hardware Entwickler). In den Tags liegen > schließlich auch die 'Deliverables', und das sind zumeist binaries. Ohje, der nächste der nicht verstanden hat was in die Versionierung kommt und was nicht. Also zum mitschreiben nochmal: Sourcecode, Hardwaredesigns kommen ins Repo, daraus gebaute Artefakte legt der Buildserver irgendwo zentral ab, Datenblätter und sonstige Doku archiviert man bei der Doku.
vnnn schrieb: > Ohje, der nächste der nicht verstanden hat was in die Versionierung > kommt und was nicht. > > Also zum mitschreiben nochmal: Sourcecode, Hardwaredesigns kommen ins > Repo, daraus gebaute Artefakte legt der Buildserver irgendwo zentral ab, > Datenblätter und sonstige Doku archiviert man bei der Doku. Und das bestimmst du einfach mal so? Weil du das so machst, und es darum überall und in jeder Situation richtig sein muss? Es könnte Gründe geben, warum andere das anders machen. Vielleicht denkst du da einfach mal drüber nach...
Matthi schrieb: > Und das bestimmst du einfach mal so? Sagen wir mal so, wenn es die halbe Welt aus sehr, sehr guten Gründen (allein schon die Reproduzierbarkeit, gibt nix schlimmeres als wenn Version 1.0 auf Entwicklungsrechner A und 1.1 auf Entwicklungsrechner B gebaut wurde) so macht, dann kannst du davon ausgehen dass es durchaus Sinn macht. Matthi schrieb: > s könnte Gründe > geben, warum andere das anders machen. Natürlich. Aber welche wären das? Matthi schrieb: > Vielleicht denkst du da einfach > mal drüber nach... Ich würde mal drüber nachdenken ob einem da wirklich hunderte Geisterfahrer entgegen kommen.
Andreas S. schrieb: > Gerade die archivierten Artefakte erlauben es doch, einen Debugger auf > alte Versionsstände loszulassen, ohne vorher einen Build mit einer > womöglich nicht mehr genau reproduzierbaren Toolchain durchzuführen. Genau das stellt man doch mit reproduzierbaren Builds sicher. Und checkst du wirklich ein Binary mit Debug Infos ein?! Bei einem reproduzierbaren Build stellt man sicher, dass die Toolchain von Null auf in einem Container/Maschine installiert wird. Diese Konfiguration speichert man natürlich. Bei finalen Releases archiviert man den Container bzw. dessen Quellen und bekommt 1:1 die Tools sollte man sie erneut benötigen. Dann kannst damit deinen minimalen Hotfix erstellen. Im Idealfall erhält man einen bitidentisches Artefakt, manchmal ist das jedoch aufgrund von z.B. Signaturen nicht möglich. In Releases landet dabei auch nur ein Artefakt welches der CI entspringt. Binary von Entwickler-Rechnern sieht man grundsätzlich als nicht reproduzierbar an (wurden ja nicht mit dem besagten Container erstellt), sprich man hat nicht alle Infos um das Ergebnis zu reproduzieren. Und das ist mein Anspruch an Softwareentwicklung im aktuellen Jahrtausend.
Binaries mit dem Code zusammen einzuchecken, ist keine gute Idee. Aber es ist grundsätzlich keine so schlechte idee, die im Repo zu haben. Man muss ja nicht alle Objekte im Git holen. Wenn man die Binaries einchecken will, aber nicht zusammen mit dem Rest, könnte man die in einen eigenen Branche packen. z.B. so:
1 | #!sh
|
2 | |
3 | # Build verzeichnis vorbereiten
|
4 | ref="$(git rev-parse HEAD)" |
5 | mkdur -p "build/$ref" |
6 | cd "build/$ref" |
7 | git init |
8 | git remote add local ../..
|
9 | git checkout --orphan "build/$ref" |
10 | |
11 | # Build
|
12 | cmake ../.. |
13 | make |
14 | |
15 | # Als commit ins lokale repo als eigenen Branch packen
|
16 | git add .
|
17 | git commit -m "Build $ref" |
18 | git push -u local "build/$ref" |
19 | |
20 | # Aufräumen
|
21 | cd "../.." |
22 | rm -rf "build/$ref" |
23 | |
24 | # Auf server pushen
|
25 | git push origin "build/$ref":"build/$ref" |
Das kann man natürlich auch die CI/CD pipeline erledigen lassen. Oder bei sich in ein Script packen. Oder ins makefile. Wie es halt am besten passt. Wenn man dann den Build brauch, kann man den einfach clonen:
1 | git clone -b build/eae685d582276048a20305a214659d3175ac90b7 ./meinrepo/ |
2 | cd build/eae685d582276048a20305a214659d3175ac90b7 |
./meinrepo/ kann das lokal ausgecheckt sein. Aber man könnte natürlich auch eins von einem Server nehmen und da angeben, muss dann halt runter geladen werden. Wenn man fertig ist, einfach den Ordner wieder löschen.
Der Vorteil davon ist, dass es nicht vom Webfrontend (gitlab/gitea) abhängig ist, und man trotzdem alles zusammen hat, und weiss, was zusammen gehört. Nachteil ist, das Repo wird etwas grösser, und man hat viele build/* branches. Aber wenn man sie nicht mer braucht, kann man sie ja wieder löschen, und die nicht mehr benötigten Objekte in Git bereinigen lassen.
🐧 DPA 🐧 schrieb: > Der Vorteil davon ist, dass es nicht vom Webfrontend (gitlab/gitea) > abhängig ist, und man trotzdem alles zusammen hat, und weiss, was > zusammen gehört. Wenn du die Artefakte mit z.B. artifactory archivierst speichert die CI passend dazu die Metadaten wie z.B. den genauen Commit aus der Versionsverwaltung. Als Beispiel mit einem Screenshot davon: https://stackoverflow.com/questions/32190267/using-git-sha-commit-id-as-artifact-version-number-when-publishing-to-artifactor Mit dieser Revision bekommst du nun dein Artefakt, das könntest du dir jetzt in dein Skript Konstrukt einbauen. Dann hast du keine Binärdaten in der Versionsverwaltung, aber sofern du sie benötigst von der CI gebaute Artefakte. So etwas kann man natürlich auch noch an die regulären git Befehle anhängen wobei ich das noch nie gemacht habe: https://git-scm.com/docs/githooks
vnnn schrieb: > Wühlhase schrieb: >> Ich denke, ich kann die Leistungsfähigkeit von git durchaus beurteilen, >> auch wenn ich es momentan nicht aktiv benutze. > > Stimmt, du hast ja schon ein Buch drüber gelesen :) Sagen wir mal, es reicht um die Verwendung von git oder SVN als sinnvoller einzuschätzen. Und mehr wollte ich damals auch nicht, und mehr will der TS hier nicht. Und es führt auf jeden Fall weiter als ein kurzes Minimaltutorial durchzugehen. vnnn schrieb: > Wühlhase schrieb: >> Naja, das Prinzip alles auf einen zentralen Server zu schmeißen wäre >> durchaus genau das, was die meisten wahrscheinlich erstmal erwarten >> würden, mir war das damals jedenfalls sofort logisch. > > Abgesehen davon dass du das Thema schon wieder verfehlst, weil der TS > keinen Server verwenden sondern offline versionieren will: du kannst git > auch problemlos mit zentralem Server verwenden, ist auch mit Abstand der > häufigste Use Case Das Thema war die Frage, an welcher Stelle SVN einfacher als git wäre, und zwar gestellt von Yalu und nicht vom TS. Was qualifiziert dich Knallbirne eigentlich zur Teilnahme an einer Diskussion (egal um welches Thema es geht), wenn du nichtmal in der Lage bist dem Gesprächsverlauf zu folgen?
Wühlhase schrieb: > Sagen wir mal, es reicht um die Verwendung von git oder SVN als > sinnvoller einzuschätzen. Und mehr wollte ich damals auch nicht, und > mehr will der TS hier nicht. Absurd. Hier sind Leute, die beide Systeme jahrelang selbst im Einsatz haben und hatten, aber du weißt alles besser, weil du ja schon mal ein Buch drüber gelesen hast. Kann man sich echt nicht ausdenken sowas. Wühlhase schrieb: > Das Thema war die Frage, an welcher Stelle SVN einfacher als git wäre, > und zwar gestellt von Yalu und nicht vom TS. Erstmal ist das Primärthemadie Frage vom TS, aber vermutlich weißt du auch besser als der was er eigentlich wissen will. Zweitens schaffst du es immer noch nicht zu erklären warum git nun komplizierter sein soll. Drittens ist es, wie bereits erwähnt, auch bei git problemlos möglich einen zentralen Server zu verwenden so man es will, nicht komplizierter als bei SVN, sogar einfacher, weils neben selbst hosten noch drölf Cloudanbieter gibt. Auch wenns nach wie vor eine Themenverfehlung ist, der TS hat immer noch nach offline gefragt. Wühlhase schrieb: > Was qualifiziert dich Knallbirne eigentlich zur Teilnahme an einer > Diskussion (egal um welches Thema es geht), wenn du nichtmal in der Lage > bist dem Gesprächsverlauf zu folgen? Was qualifiziert dich Scherzkeks eigentlich zu irgendeinem Kommentar zu git, wenn du es noch nie in produktivem Einsatz hattest? Absurd, dein Geschwafel. Und du kapierst nicht mal dass der TS nie nach einer Serverlösung gefragt hat. Es ist so peinlich.
vnnn schrieb: > [..] Machen wir es einfach so: Du hast Recht, ich meine Ruhe. :) Den Kindergarten, daß das eine Programm für alle Probleme dieser Welt die ultimative Lösung ist, tue ich mir schon im Platinenforum mit Layoutprogrammen an.
Wühlhase schrieb: > daß das eine Programm für alle Probleme dieser Welt > die ultimative Lösung ist Dabei hab ich das doch nirgends behauptet. Im Gegenteil, rate ich doch explizit dazu, Buildartefakte und Dokumentation doch wo anders zu hinterlegen. Absurd, was du dir so ausdenkst, wenn du nicht gerade am Thema (Offlineversionierung) vorbei irgendwas von Servern redest, oder über Dinge redest die nur aus Büchern kennst.
vnnn schrieb: > Datenblätter und sonstige Doku archiviert man bei der Doku. Es spricht, abgesehen vom Platzbedarf, absolut nichts dagegen, auch die Datenblätter und Doku in ein Versionscontrolsystem zu stecken. Datenblätter und Doku haben oft auch Revisionen, jetzt stell dir mal vor, dass bei einer aktuelle Revision eines Datasheets Informationen entfernt wurden, die im alten noch drin standen. Du hast dein Datasheet in einen Ordner Namens "Doku" ohne Versionierung gepackt und das alte Datasheet damit überschrieben. Wie rekonstruierst du nun das alte bzw. kommst an dieses ran? Geht nicht. Mit einem VCS ist es ein leichtes, an das alte Datasheet heranzukommen. So und um nochmal auf den Platzbedarf zurückzukommen. Das war vielleicht vor 30 Jahren ein Thema, aber doch nicht mehr heute, wo man TB große Datenträger bekommt.
A. S. schrieb: > Der Vorteil bei Tortoise (SVN auf einem Windows PC): Du > installierst > Tortoise/SVN auf Deinem Rechner, nimmst einen leeren Ordner und > eröffnest dort mit der rechten Maustaste ein neues Repository. Ohne > Webgedöns, Server oder was weiß ich. Innerhalb von Minuten kannst Du > lokal loslegen, notfalls ohne Internet auf einem Uraltrechner. Anstatt ein VCS mitsamt Repo nur lokal auf dem gleichen Rechner, mit dem man arbeitet, zu installieren, bietet es sich an, dafür gleich ein NAS zu verwenden und das VCS als Serverdienst auf dem NAS laufen zu lassen. Das hat mehrere Vorteile: 1. die verfügbaren out of the box NAS Systeme bieten eine leichte Installation und Einrichtung von GIT und SVN an. 2. Auf einem NAS verwendet man eher Redundanz in Form eines Mirrors oder RAID 5, als auf dem Arbeitsrechner, wo das eher selten ist. 3. Auf einem NAS sind die Daten besser vor Schadsoftware geschützt. 4. Man lernt so gleich die Remotebenutzung der VCS. Das ganze ist dann immer noch offline, so wie es der TS wollte. Er benötigt lediglich ein LAN/WLAN und ein NAS.
Noch was vergessen: Nano schrieb: > Das hat mehrere Vorteile: 5. das Repo ist dank NAS von mehreren Rechnern und Systemen aus zugänglich. Wer zwischen verschiedenen Betriebssystemen oder Rechner wechselt wird das zu schätzen wissen.
Gibt es einen anderen Grund als Nostalgie um heute noch SVN zu lernen? Klar fehlt bei SVN einiges, für einfache Fälle ist es einfacher, aber der Aufwand SVN zu erlernen ist IMO Zeitverschwendung. Git kann all das was SVN kann und viel mehr, in der Berufswelt ist SVN selten anzutreffen, eigentlich nur da wo man sich dem Fortschritt verwehrt, also we Technik und Innovation nebensächlich sind.
Ein Grund Git nicht in der Firma einzusetzen könnte git rebase sein. Ein sehr schöner Befehl um Commits aufzuräumen z.B. um kleine Tippfehlerkorrekturen mit dem Ursprungscommit zu verschmelzen. Damit wird aber effektiv die Versionshistorie manipuliert was unter Umständen nicht akzeptabel ist. Gibt es eine technische Möglichkeit im zentralen Repo das zu verhindern oder nur über Arbeitsanweisungen die die Nutzung zu verbieten? Am besten so dass es lokal weiterhin möglich ist um vor einem Push die neuen Commits aufzuräumen.
Bei git ist bei Änderungen der Versionshistorie generell kein normaler push möglich, sondern nur ein force-push. Und ja, das kann man auch einschränken. Bei den ganzen Weboberflächen für die Repos (github, gitlab, gitea, etc.) kann man das sogar bequem per Webfrontend einstellen, oder auch die Berechtigung je nach User vergeben.
Ja man kann konfigurieren auf welchen Branches Force Push erlaubt ist. Eine Sache die git nicht kann, aber SVN: locken von Dateien das gab es gaaaanz früher mal in komplett veralteten Versionsverwaltungssystemen (CVS, Rational ClearCase, etc. pp.), die SVN User haben sich solange beschwert, bis das "feature" kam. Das ist natürlich bei git anders, bescheuerte Features gibt es nicht auf Anfrage, egal wieviele das wollen.
Ein Grund, ein eigentlich veraltetes VCS einzusetzen, sind langlebige legacy-Anwendungen. Wir haben so eine in der Firma: Mitte der 90er auf Workstations mit CVS verwaltet, um 2000 nach Windows portiert und dann Visual SourceSafe eingesetzt (dafür braucht man gute Nerven), dann um 2014 auf SVN übertragen. Dabei ging jedesmal die Versionsgeschichte verloren. Für Neuprojekte ist bei uns SVN nicht mehr zulässig, jetzt muss es git sein. Irgendwann in ein paar Jahren wird dann ein neuer Projektleiter als erste Amtshandlung die Migration von SVN auf git befehlen. Bis dann der nächste heisse Shice kommt. Will sagen: Viel wichtiger, welches VCS man einsetzt, ist doch, dass man überhaupt eins verwendet (und am besten noch ein paar Regeln dazu vereinbart).
Auf der Arbeit müssen wir inzwischen Git benutzen. Ich empfinde SVN insbesondere mit der GUI von Tortoise als deutlich einfacher anzuwenden. Aber Git ist auch OK, kann man ebenfalls ohne Server benutzen.
Wühlhase schrieb: > Besser ist git auch nur, wenn man es braucht. Und mit git muß man sich > deutlich länger beschäftigen als mit SVN. Man muß sich nur dann mit den erweiterten Features von Git beschäftigen, wenn man sie braucht. Wenn nicht, ist der Einarbeitungsaufwand derselbe. Aber wenn man die Features braucht, hat man sie schon und muß nicht erst auf eine andere Versionskontrolle wechseln, um sie nutzen zu können. Der Newcomer Git hat das ältere Subversion aus guten Gründen überholt, wenn nicht sogar abgehängt hat: Gits höhere Geschwindigkeit kommt auch Usern zugute, die seine fortgeschrittenen Features nicht nutzen, hinzu kommen schicke Features wie der Offline-Support und das elegantere Branching. Insofern finde ich Deine Ausführungen ein wenig verkürzt, sorry.
A. S. schrieb: > Der Vorteil bei Tortoise (SVN auf einem Windows PC): Du installierst > Tortoise/SVN auf Deinem Rechner, nimmst einen leeren Ordner und > eröffnest dort mit der rechten Maustaste ein neues Repository. Ohne > Webgedöns, Server oder was weiß ich. Innerhalb von Minuten kannst Du > lokal loslegen, notfalls ohne Internet auf einem Uraltrechner. > > Du kannst Dich dann in SVN reinfuchsen, Du kannst aber auch alles mit > der rechten Maustaste machen. Das erleichtert den Einstieg ungemein. All das geht mit Git und TortoiseGit ganz genauso.
Peter Pan schrieb: > Es gibt sture alte Hasen die daran festhalten, aber in der Realität ist > [SVN] umständlich und Müll. Bitte, Peter, komm' mal 'runter. Subversion ist Git zwar unterlegen -- und das zeigen ja auch die Nutzerstatistiken, in denen Git Subversion haushoch abgehängt hat -- aber "umständlich" oder gar "Müll" ist es deswegen noch lange nicht. Auch wenn es dank dezentralisierter Wettbewerber wie Git und Mercurial nicht mehr ganz state-of-the-art ist, ist und bleibt Subversion ein leistungsfähiges zentrales Versionskontrollsystem.
Wühlhase schrieb: > Peter Pan schrieb: >> Alles was man für einfaches Arbeiten mit git benötigt kann man sich in >> wenigen Minuten anlesen. > [...] > Höre auf diesen Unsinn zu verbreiten, > daß man in ein paar Minuten zum git-Profi wird. Man wird nicht in ein paar Minuten zum Git-Profi, aber man wird in dieser Zeit auch nicht zum Subversion-Profi. Aber die Basics für einen Einstieg kann man bei beiden Systemen in wenigen Minuten erlernen.
Lutz Legacy schrieb: > Ein Grund, ein eigentlich veraltetes VCS einzusetzen, sind langlebige > legacy-Anwendungen. Wir haben so eine in der Firma: Mitte der 90er auf > Workstations mit CVS verwaltet, um 2000 nach Windows portiert und dann > Visual SourceSafe eingesetzt (dafür braucht man gute Nerven), dann um > 2014 auf SVN übertragen. Dabei ging jedesmal die Versionsgeschichte > verloren. Wie das mit "SourceSafe" ist, weiß ich nicht, aber ich habe Repos von CVS über SVN nach GIT umgezogen, immer inklusive History, Branches und Tags und den verschiedenen Benutzern. Das ging nicht per einfachem Mausklick, und man musste schon etwas Zeit investieren, aber es ging. Ein T. schrieb: >> Du kannst Dich dann in SVN reinfuchsen, Du kannst aber auch alles mit >> der rechten Maustaste machen. Das erleichtert den Einstieg ungemein. > > All das geht mit Git und TortoiseGit ganz genauso. Und auf der Kommandozeile geht es mit git einfacher als mit svn:
1 | git init |
und fertig. Schon hat man ein lokales Repository inklusive ausgecheckter Arbeitskopie, bereit für den ersten Commit.
Matthi schrieb: > vnnn schrieb: >> Also zum mitschreiben nochmal: Sourcecode, Hardwaredesigns kommen ins >> Repo, daraus gebaute Artefakte legt der Buildserver irgendwo zentral ab, >> Datenblätter und sonstige Doku archiviert man bei der Doku. > > Und das bestimmst du einfach mal so? Weil du das so machst, und es darum > überall und in jeder Situation richtig sein muss? Naja, sagen wir mal so: Versionskontrollsoftware für Quelltexte ist in der Regel für, nunja, Quelltexte ausgelegt. Also Plaintext-Dateien, in denen dann einzelne Zeilen hinzugefügt, verändert oder gelöscht werden. Deshalb sind sie für binäre Dateien üblicherweise nicht optimiert und nicht so gut geeignet. Für Git gibt es deswegen für Binärdateien und Ähnliches eigens die Erweiterung namens "Large File Storage" (git lfs), Subversion dagegen kann IIRC Binärdateien erkennen und behandelt sie anders als Textdateien.
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.