fat-lobyte hat geschrieben:Das entspricht quasi einem Clone.
Das ist Teil des Problems, dass ein "branch" einem "clone" entspricht. Aber ich schweife ab.
quasi!
Die Idee ist einfach eine andere.
fat-lobyte hat geschrieben:Und was sind komplizierte Merges!? Konflikte sind notwendig, wenn der Computer nicht entscheiden kann, wie hier richtig gemergt werden muss.
Das ist natürlich richtig, aber hier kann einem das VCS viel arbeit abnehmen, und nur Konflikte anzeigen, die wirklich Konflikte sind.
Subversion denkt sich die Konflikte nicht selbst aus... ^^
fat-lobyte hat geschrieben:Vielleicht sollte man noch dazu sagen, dass git nicht nur auf eine Weise, sondern auf
mehrere Arten
Hier sehe ich, dass git mit Whitespaces eventuell besser klarkommt.
Das ist super - ehrlich! Aber ein bisschen mager, um die Installation zu rechtfertigen.
fat-lobyte hat geschrieben:Wenn Du eine Datei veränderst, die ich gelöscht habe, dann passt das so nicht, dann muss Subversion melden, dass das so nicht zusammen passt. Und ich gehe mal schwer davon aus, dass git hier nicht anders handelt.
Wenn du die Datei umbenannt hast, kann Git es manchmal erkennen.
Das hoffe ich, denn das wurde lange Zeit als der große Vorteil gegenüber SVN gehandelt.
Darum habe ich die Datei gelöscht und das ist ein Problem. Da hilft es auch nicht, dass Git anderswo Vorteile hat.
Das Umbenennen einer Datei ist - genauso wie das Löschen - kaum als alltäglich zu bezeichnen. Alltäglicher wäre das Hinzufügen. Fügen wir beide eine Datei ab.c hinzu haben wir das gleiche Problem: Konflikt. Um so einen Kleinkram mag ich gar nicht diskutieren. Schön, dass git verteilt werden kann. Wenn man es braucht, absolut ein Vorteil von git. Streitet keiner ab. Ich brauche es gerade nicht. git kann (fast) zwar alles besser, aber in dem Punkten, wo es für mich wichtig ist, ist git unbrauchbar.
Hier in der Firma wäre git vermutlich komplett unbenutzbar, alleine der Weg von SourceSafe zu Subversion ist hart. Dass mehrere Leute gleichzeitig an einer Datei arbeiten können, alles Teufelswerk! SVN funktioniert hier jetzt seit drei Jahren absolut problemlos, aber viele vertrauen immernoch nicht darauf. Wenn SVN streikt, dann weil die Leute Mist gebaut haben und es streiken muss. Noch heute ist manchem ein einfacher Copy-Befehl zu kompliziert, um einen Branch zu erzeugen. Subversion funktioniert eigentlich sehr einfach, aber das muss man erstmal vermittelt bekommen.
Für die Umsetzung von SourceSafe auf SVN habe ich hier gut 2 Jahre Überzeugungsarbeit leisten müssen. git verteilt auch noch die Repositorys. Sowas würde hier aufgenommen, als würde man versuchen ein Gartenlaube unter zu Hilfename von Dynamit zu bauen.
Ich bin hier auf proggen.org Admin, ich brauche die Vorteile bei der Installation und Wartung. Ich möchte gerne git bereitstellen, aber entweder arbeitet man mir hier zu oder nicht. Du meintest mal, dass Du da keine Lust/Zeit zu hast, ich habe hier Administration - wir sind im letzten Jahr noch oft genug umgezogen - eigene Tutorials, das Design, etliches zu programmieren und komme da schon nicht in akzeptabler Geschwindigkeit weiter. Und das sind nur die Bausstellen, die bei proggen.org liegen. Die Fehlermeldungen zum Design lasse ich ja auch nicht ewig liegen, weil mir nichts daran liegen würde. Da stehen halt auch noch Baustellen, die man halt nicht so offen sieht.
Git hat diesbezüglich eine sehr niedrige Priorität, solange wir nichtmals ein git-Tutorial haben, geschweige denn einen Autor, der es vorantreibt oder irgendwer, der sich darum mit kümmern will und kann.
Wenn ich Zeit dafür habe, kaufe ich mir gerne ein passendes Buch. Aber das bedeutet, dass in den nächsten 2 Jahren kein Git-Service zu erwarten ist.
fat-lobyte hat geschrieben:Musste man bei SVN nicht für merges irgendwie an den komischen properties manipulieren?
An Properties manipuliere ich sehr selten und in der Regel nicht wegen Merges!?
fat-lobyte hat geschrieben:git über ssh ist nicht akzeptabel. Wenn Du was anderes weißt und eine akzeptable Anleitung hast - ich bin interessiert.
Vielleicht kommen wir damit ja ins Geschäft. Gitosis ist keine Option.
Wenn das so ist, dann kann man die Diskussion mit "auf Proggen.org wird es kein Git-Hosting geben" beenden. Das mittel der Wahl ist bei Git SSH, und das ist am einfachsten.
Man muss nicht jedem Entwickler einen Benutzeraccount machen, man kann Gitolite das benutzermanagement überlassen, aber Gitolite ist auch nur die verbesserte Version von Gitosis und vom Prinzip her das gleiche.
Gitolite kenne ich noch nicht. Gitosis war damals eine mittlere Katastrophe.
Ich bin gerne bereit mich damit auseinander zu setzen, aber solange ich das alles alleine mache, habe ich genug unfertige Baustellen.
Und bevor nicht auf einem VServer ein git-Service läuft, den ich gut verstehe, landet der nicht auf dem Root-Server (um durch bei Fehlern bei der Installation vielleicht irgendein Tor zu öffnen) oder im aktiven Betrieb. Den VServer kann man jederzeit platt machen, auf dem Root-Server läuft proggen.org...
Die Server sind auch eine rechtliche Verantwortung. Was ich nicht vollständig verstehe, läuft nicht auf meinen Servern im Netz.
Also entweder hiflt man mir, indem man mir zuarbeitet, so dass das für mich wenig Aufwand bedeutet oder git ist aktuell nichts, wofür ich eine neue Baustelle aufreißen würde. So leid es mir tut, ich würde mich gerne damit beschäftigen, aber erstmal muss ich mich darauf konzentrieren, andere Baustellen zu zu bekommen.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.