wer nutzt git für private projekte?
-
DEvent schrieb:
Wie machen das die Leute mit ihren Dokumenten und Versionsverwaltung? Als Programmierer hat man es ja nur mit Textdateien zu tun, aber z.B. MS-Word Dokumente sind ja alle binaer. Ein Versionsverwaltung muesste diese Dokumente auslesen koennen und dann die Aenderungen protokolieren. Gibt es solche Programme?
wie eigentlich jedes andere scm kann git auch mit binaries umgehen und diff't eben die binärdaten und speichert die deltas (die bei binärdaten eben für gewöhnlich ziemlich groß ausfallen). der inhalt des binaries ist in dem fall irrelevant, wie bei den textdaten im grunde auch. ein scm muss nichts über den inhalt wissen, nur über differenzen. eine unterscheidung zwischen text und binary files im repo ist im grunde nur für die wahl des effizienteren packalgorithmusses (plural korrekt? :P) mit den man die deltas archiviert wichtig :xmas1:
edit: oh, natürlich steht und fällt alles mit der qualität der heurisitk mit dem das scm system text von binärdaten unterscheidet. ich habe da noch so düstere erinnerungen mit cvs und unicode-textdateien. die musste man glaube ich explizit als binary deklarieren, sonst kam datensalat beim auschecken an
-
hi
ich finde, git sieht interessant aus.
was sind die vorteile gegenueber svn oder online systemen wie google-code?
-
DEvent: Noch ein Grund mehr der für LaTeX spricht. (Nicht, dass ich vor Git und Darcs noch ernsthaft irgendwas anderes verwendet hätte.)
neulingling schrieb:
ich finde, git sieht interessant aus.
was sind die vorteile gegenueber svn oder online systemen wie google-code?
-
neulingling schrieb:
hi
ich finde, git sieht interessant aus.
was sind die vorteile gegenueber svn oder online systemen wie google-code?Der wesentliche Unterschied ist der, dass git ein dezentrales und svn ein zentrales vcs ist. Sprich bei svn braucht man immer einen Server, der das repository verwaltet. Wollen Programmierer ihre Codeänderungen austauschen, dann können sie nur über diesen Server gehen. Bei git dagegen hat jeder Rechner ein komplettes rep und ist nicht von einem Server abhängig. Man kann Änderungen auch commiten, wenn man nicht Online (oder der Server offline) ist und man kann Änderungen ohne Probleme zwischen Nutzern austauschen ohne über den Server zu gehen. Dies kann lokal geschehen (von Verzeichnis zu Verzeichnis), über ssh oder ein git eigenes Protokoll (uvm.) und git hat sogar Tools um Patches ganz einfach via Email auszutauschen. Außerdem ist git viel schneller und effizienter als svn. Bei git ist das ganze rep. idr. viel kleiner, als ein einzelner checkout bei svn!
Im Gegensatz zu svn verwaltet git Änderungen auch nicht auf Dateibasis, sondern auf Projektbasis. D.h. es ist kein Problem Dateien oder Code umzukopieren. Bei git kann man sehr komfortable branchen und mergen (zumindest letzteres ist mit svn eine Qual). Das geht sogar so gut, dass man idr sehr häufig eine neue branch aufmacht (also zB für jedes neue Feature).
Bei git wird die Versionsgeschichte kryptographisch gesichert, so dass niemand heimliche Änderungen einschleusen kann. svn besitzt so ein Feature nicht.git hat auch sehr nette Tools, so wie git-svn. Damit kann man einfach von git aus svn-Server ansprechen und so auch wenn das Projekt mit svn verwaltet wird - zumindest lokal - die Vorteile von git nutzen.
-
sothis_ schrieb:
wie eigentlich jedes andere scm kann git auch mit binaries umgehen und diff't eben die binärdaten und speichert die deltas (die bei binärdaten eben für gewöhnlich ziemlich groß ausfallen). der inhalt des binaries ist in dem fall irrelevant, wie bei den textdaten im grunde auch. ein scm muss nichts über den inhalt wissen, nur über differenzen. eine unterscheidung zwischen text und binary files im repo ist im grunde nur für die wahl des effizienteren packalgorithmusses (plural korrekt? :P) mit den man die deltas archiviert wichtig :xmas1:
Daran habe ich nicht gedacht, danke. Aber ist das ueberhaupt Praktikabel? Das wichtigeste an einem VCS ist ja das zusammenführen ("merge") von Dateien. Wie soll man das bitte mit binaer-Daten machen?
Git protokoliert z.B. auch, welcher Autor welche Quellcode-Zeile abgemeldet (also "checkout") hat. Wie soll man sowas bei binaer-Daten machen?
-
DEvent schrieb:
sothis_ schrieb:
wie eigentlich jedes andere scm kann git auch mit binaries umgehen und diff't eben die binärdaten und speichert die deltas (die bei binärdaten eben für gewöhnlich ziemlich groß ausfallen). der inhalt des binaries ist in dem fall irrelevant, wie bei den textdaten im grunde auch. ein scm muss nichts über den inhalt wissen, nur über differenzen. eine unterscheidung zwischen text und binary files im repo ist im grunde nur für die wahl des effizienteren packalgorithmusses (plural korrekt? :P) mit den man die deltas archiviert wichtig :xmas1:
Daran habe ich nicht gedacht, danke. Aber ist das ueberhaupt Praktikabel? Das wichtigeste an einem VCS ist ja das zusammenführen ("merge") von Dateien. Wie soll man das bitte mit binaer-Daten machen?
Quatsch, das Mergen von halbwegs interessanten Problemen muss man eh per Hand machen.
Außerdem will hier doch niemand Binärdateien darin speichern. Du legst ja auch keine .exe in dein Repo ab, sondern den Quellcode, warum sollte man es bei einem Dokument anders machen?btw. gibt es entsprechende binär-diff- und -merge-tools.
DEvent schrieb:
Git protokoliert z.B. auch, welcher Autor welche Quellcode-Zeile abgemeldet (also "checkout") hat. Wie soll man sowas bei binaer-Daten machen?
? Wie soll das gehen bei einem dezentralen system
-
Versionsverwalter schrieb:
Außerdem will hier doch niemand Binärdateien darin speichern. Du legst ja auch keine .exe in dein Repo ab, sondern den Quellcode, warum sollte man es bei einem Dokument anders machen?
Word Dokumente sind aber binaer-Daten. Darum geht es mir doch. Dort gibt es keinen "Quellcode". ODF ist ein Textformat, wie Latex oder html.
Versionsverwalter schrieb:
DEvent schrieb:
Git protokoliert z.B. auch, welcher Autor welche Quellcode-Zeile abgemeldet (also "checkout") hat. Wie soll man sowas bei binaer-Daten machen?
? Wie soll das gehen bei einem dezentralen system
Probier es doch aus:
http://www.kernel.org/pub/software/scm/git/docs/git-blame.html (IMHO ein sehr passender Name des Programms).
-
DEvent schrieb:
Das wichtigeste an einem VCS ist ja das zusammenführen ("merge") von Dateien.
Ich dachte immer das wichtigste wäre es Versionen zu verwalten. So kann man sich täuschen.
-
rüdiger schrieb:
Der wesentliche Unterschied ist der, dass git ein dezentrales und svn ein zentrales vcs ist. Sprich bei svn braucht man immer einen Server, der das repository verwaltet. Wollen Programmierer ihre Codeänderungen austauschen, dann können sie nur über diesen Server gehen.
wer sowas mit svn machen will, kann das repository doch auf seinen rechner kopieren. so wesentlich scheint mir der unterschied nicht zu sein, ausser, dass bei svn mehr handarbeit dafür nötig ist.
-
Joah, aber wenn du zum Beispiel ein Programm auf mehreren Rechnern entwickeln willst, musst du vor jedem Rechnerwechsel das Repo synchronisieren (wenn du keinen Server hast), wenn mir nicht irgendwas entgangen ist. Das ist bei git nicht nötig.
-
DEvent schrieb:
Word Dokumente sind aber binaer-Daten. Darum geht es mir doch. Dort gibt es keinen "Quellcode". ODF ist ein Textformat, wie Latex oder html.
Ein weiterer Grund vernünftige Textformate zu verwenden. (Und nein, ODF ist keines davon.)
fricky:
- Geht nur für Admins eines eigenen Subversion-Systems.
- Mergen/Synchronisieren ist danach extrem mühsam.
- Ein komplettes Git-Repository ist kleiner als ein einzelner SVN-Checkout.
- Das ist enormer händischer Aufwand, den _jeder_ Entwickler auf sich nehmen muss.
- Alleine für die Idee sollte Dir Deine SCM-Lizenz entzogen werden.
-
~fricky schrieb:
rüdiger schrieb:
Der wesentliche Unterschied ist der, dass git ein dezentrales und svn ein zentrales vcs ist. Sprich bei svn braucht man immer einen Server, der das repository verwaltet. Wollen Programmierer ihre Codeänderungen austauschen, dann können sie nur über diesen Server gehen.
wer sowas mit svn machen will, kann das repository doch auf seinen rechner kopieren. so wesentlich scheint mir der unterschied nicht zu sein, ausser, dass bei svn mehr handarbeit dafür nötig ist.
Aber dann können sie ihre Versionen auch nicht verwalten lassen und das sollte doch der Sinn von svn sein
.
-
ich sage ja nicht, dass es eine besonders tolle idee ist, alles zig-fach auf mehreren rechnern zu speichern. aber wer's braucht, kriegt das bestimmt auch mit svn hin. wahrscheinlich gibts schon fertige tools die das synchronisieren erleichtern usw.
-
Und was genau hätte das für Vorteile gegenüber git-svn?
-
nman schrieb:
Und was genau hätte das für Vorteile gegenüber git-svn?
z.b. dass man nicht mit zwei unterschiedlichen vcs rumfummeln muss.
-
~fricky schrieb:
nman schrieb:
Und was genau hätte das für Vorteile gegenüber git-svn?
z.b. dass man nicht mit zwei unterschiedlichen vcs rumfummeln muss.
Muss man ja nicht, wenn man git-svn hat. Dann sieht svn ja so aus, als wäre es git. Und man kann die Vorteile von git nutzen (und da gibt es ja einige).
~fricky schrieb:
ich sage ja nicht, dass es eine besonders tolle idee ist, alles zig-fach auf mehreren rechnern zu speichern. aber wer's braucht, kriegt das bestimmt auch mit svn hin. wahrscheinlich gibts schon fertige tools die das synchronisieren erleichtern usw.
Du bekommst es halt nur hin, wenn du SVN umgehst (=> keine Versionsverwaltung für deine Kopien) und dann kannst du gleich auf SVN verzichten.
-
~fricky schrieb:
rüdiger schrieb:
Der wesentliche Unterschied ist der, dass git ein dezentrales und svn ein zentrales vcs ist. Sprich bei svn braucht man immer einen Server, der das repository verwaltet. Wollen Programmierer ihre Codeänderungen austauschen, dann können sie nur über diesen Server gehen.
wer sowas mit svn machen will, kann das repository doch auf seinen rechner kopieren. so wesentlich scheint mir der unterschied nicht zu sein, ausser, dass bei svn mehr handarbeit dafür nötig ist.
Du musst aber auch alle branchs aller Entwickler mit kopieren. Mit git kannst du soviele branchs erstellen wie du willst, davon bekommst nur du was mit und nicht alle anderen. Das ist ja der Vorteil von dezentralen VCS.
-
Weil wir den Thread gerade haben:
Die GitHub-Leute sind wirklich cool:
http://code.google.com/p/tortoisegit/
-
nman schrieb:
Weil wir den Thread gerade haben:
Die GitHub-Leute sind wirklich cool:
http://code.google.com/p/tortoisegit/However, none of us here at Logical Awesome use Windows (or really want to spend that much time in it), so we’d like to issue a challenge.
lol, aber ne gute idee
-
sothis_ schrieb:
nman schrieb:
Weil wir den Thread gerade haben:
Die GitHub-Leute sind wirklich cool:
http://code.google.com/p/tortoisegit/However, none of us here at Logical Awesome use Windows (or really want to spend that much time in it), so we’d like to issue a challenge.
lol, aber ne gute idee
Bis auf die Idee mit Python.
Python ist zwar ne schöne Sprache, aber wenn dann das kleine Fuzzelprogramm
100 MB Schluckt, nur weil Python und GTK+ noch mitinstalliert werden,
dann läuft was falsch.Denn genau bei Windows ist das ein Problem, weil es dort keine Distributionen für Open Source Software gibt, wo man Python und GTK+ in eigenen Paketen verwalten könnte.
So kommt es also, daß jedes Windows Programm, daß Python oder GTK+ verwendet,
seine eigene Python und GTK+ Version mitliefert und das ist einfach Müll.Erst gestern habe ich den Torrent Client Deluge auf meinem
Notebook installiert und festgestellt, daß das ganze Ding gleich 120 MB schluckt, weil es sein eigenes Python und GTK+ mitliefert.
Da war mir das ganze dann zu blöd und ich habe uTorrent installiert,
das braucht auf der Festplatte nur 0,265 MB.Ersparnis 99,8 % und das bei gleicher Funktionalität.
Es geht also nichts über reine C Anwendungen die direkt mit der Winapi linken.
Wenn das Programm eh nur direkt für Windows entwickelt wird und auch nicht Crossplattformfähig sein soll, wie eben Tortoise, dann kann man es kaum besser machen.