wer nutzt git für private projekte?
-
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.
-
also die verlinkte variante hat meines erachtens keine python abhängigkeit :S
-
Ballast schrieb:
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.Benutz halt Linux
-
DEvent schrieb:
Ballast schrieb:
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.Benutz halt Linux
Würde ich ja gerne, aber ich wollte neben dem Torrentdownload nebenbei in Ruhe ein sehr gutes Singleplayer Spiel spielen.
-
Ballast schrieb:
Würde ich ja gerne, aber ich wollte neben dem Torrentdownload nebenbei in Ruhe ein sehr gutes Singleplayer Spiel spielen.
jaja, alle software gratis haben wollen aber nicht auf kommerzielle produkte verzichten.. tztztz
-
Wer git unter Windows auch so scheiße findet, kann mal Bazaar anschauen.
Komme damit erheblich besser zurecht als mit diesen Krämpfen von git ports.
Kann aber ungefähr das gleiche, Wikipedia nach zu urteilen.