vcs:git:makehis

[darksider3]

Das erzähle ich ihm auch schon seit Jahren?
Aber mir glaubt er das auch nicht :->

Er sagte doch, das er sich extra "Git-Zeit" nehmen möchte:

Irgendwann mal sollte ich mir extra-Git Zeit reservieren.

[fat-lobyte]

Aus einem anderen Thread

Sobald ich getestet habe, ob Dedupe mit den jetzigen Modifikationen auch auf Linux kompiliert, gibt es wieder mal einen SVN Commit.

Ok, somit hat sich meine Meinung zu Subversion von "notwendiges Übel" zu "Plage von Entwicklern" geändert.

Es darf niemals, niemals, niemalsnie passieren, dass Entwickler davon abgehalten werden etwas zu commiten. Sei es aus "sichtbarkeitsgründen" (ich kann ja keinen kaputten Code comitten), weil ihm die Berechtigungen fehlen, weil es "zu viel Aufwand" ist und nicht mal wenn das Internet gerade nicht funktioniert.
Und das ist nicht nur eine Frage von "Entwicklerdisziplin", das ist hauptsächlich eine Frage des VCS. Wenn das VCS "Spaß macht", dann hat auch keiner ein Problem damit.

Ich sehe keinen Grund mehr, wieso man Subversion Git vorziehen sollte, und ich sehe auch keinen Grund mehr nicht alle SVN repositories auf Git umzustellen.

[Xin]

Aus einem anderen Thread

Sobald ich getestet habe, ob Dedupe mit den jetzigen Modifikationen auch auf Linux kompiliert, gibt es wieder mal einen SVN Commit.

Ok, somit hat sich meine Meinung zu Subversion von "notwendiges Übel" zu "Plage von Entwicklern" geändert.

Es darf niemals, niemals, niemalsnie passieren, dass Entwickler davon abgehalten werden etwas zu commiten.

Deine Meinung zeigt nur, dass Du mit Subversion nicht umgehen kannst. Nicht Subversion hält ihn davon ab, zu committen, sondern seine Arbeitsweise.

Bebu kennt offenbar auch die Arbeitsweise noch nicht, weswegen er - sinnvoll! - erstmal überlegt, nicht in den trunk zu committen. Die Alternativen scheinen euch beiden nicht bewusst zu sein.
Was bedeutet, dass ich mein Subversion-Tut dringend wieder in Angriff nehmen sollte...

[darksider3]

Ok, somit hat sich meine Meinung zu Subversion von "notwendiges Übel" zu "Plage von Entwicklern" geändert.

...

s darf niemals, niemals, niemalsnie passieren,

Niemals,Niemals,niemalsnie und niemalsnicht

Ich sehe keinen Grund mehr, wieso man Subversion Git vorziehen sollte, und ich sehe auch keinen Grund mehr nicht alle SVN repositories auf Git umzustellen.

Dass musst du erstmal Sascha erklären... Er sieht Git als das Übel an, und SVN ist das Heiligtum^^

Deine Meinung zeigt nur, dass Du mit Subversion nicht umgehen kannst. Nicht Subversion hält ihn davon ab, zu committen, sondern seine Arbeitsweise.

SVN ist veraltet... Ausserdem ist eine Meinung eben das selbige: Eine Meinung! Gleich wird hier über Schockoladen- und Erdbeereis gestritten, ich sehs schon kommen

[cloidnerux]

Gleich wird hier über Schockoladen- und Erdbeereis gestritten,

Nur Schokoladeneis ist das einzig wahre, wer etwas anderes Behauptet hat keine Ahnung und frisst kleine Kinder!

Aber mal ehrlich, SVN ist nicht böse und auch nicht schlecht, es hat auch Vorzüge und das gleiche gilt für Git.
Ist wieder so eine Grundsatzdiskussion wie zwischen Windows und Linux(-distributionen) oder iPhone vs Android etc.
Also sollten wir nicht über Sinn und Unsinn streiten...

[Xin]

SVN ist veraltet...

SVN und GIT sind Versionsverwaltungen. Das bedeutet aber nicht, dass sie das selbe Problem lösen.

Gleich wird hier über Schockoladen- und Erdbeereis gestritten,

Nur Schokoladeneis ist das einzig wahre, wer etwas anderes Behauptet hat keine Ahnung und frisst kleine Kinder!

Schockoladierend.

Aber mal ehrlich, SVN ist nicht böse und auch nicht schlecht, es hat auch Vorzüge und das gleiche gilt für Git.

Und das ist eben der Punkt - Subversion als "Plage für die Programmierer" darzustellen ist falsch.
Das ist nicht eine Frage von "Ich mag Subversion und du hast mit Deinem Schäufelchen auf meine Subversion-Sandburg gehauen", sondern eben daher, da fat-lobyte gerne gegen Subversion wettert, aber ihm die Verwendung von Subversion offenbar gar nicht so geläufig ist. Ich wettere ja auch nicht gegen git, schließlich kenne ich es auch nicht gut genug - ich benutze halt SVN, weil ich damit umgehen gut kann und es nunmal meine Probleme sehr einfach löst und sich git beim damaligen Installationsversuch sich ziemlich quer stellte. Eine Plage für die Administration gewissermaßen.

Darum haben wir hier einen Subversion-Service, aber keinen Git-Service.

[fat-lobyte]

Ein Bisschen hängt euer Schokoladeneis-vergleich schon.
Git kann fast alles, was SVN kann, und das sehr viel schneller (und wie ich finde einfacher), aber SVN kann bei weitem nicht das was Git kann.

Darum haben wir hier einen Subversion-Service, aber keinen Git-Service.

Darum lasse ich hier auch keine Projekte hosten, sondern nur auf GitHub

Außerdem habe ich dazu noch ein etwas weniger schönes Sprichwort: "was der Bauer nicht kennt, frisst er nicht."
Das gilt für Admins noch allemal mehr als für Landwirte. Das ist zwar verständlich, aber deswegen nehme ich jedes "hab ich mal probiert, war aber blöd" mit einem Körnchen vorsicht.

Es ist wahr, ich bin kein SVN-Profi, aber ich habe auch damit gearbeitet. Es ist um ein vielfaches langsamer, ich finde die Zugrundeliegende "Vorstellung" von Versionsverwaltung ist kaputt, und bei komplizierteren merges wirds bald mal haarig.
Dass mehrere Änderungsquellen nicht unterstützt werden und dass es nur ein "zentrales" repository geben kann funktioniert zwar für irgendwelche Firmen, für Open Source-Entwicklung ist das aber einfach nicht mehr Zeitgemäß.

Ich bin ohne Frage voreingenommen, das stimmt schon. Aber das ich gar keine Ahnung habe stimmt auch wieder nicht.

[Xin]

Darum haben wir hier einen Subversion-Service, aber keinen Git-Service.

Darum lasse ich hier auch keine Projekte hosten, sondern nur auf GitHub

Außerdem habe ich dazu noch ein etwas weniger schönes Sprichwort: "was der Bauer nicht kennt, frisst er nicht."
Das gilt für Admins noch allemal mehr als für Landwirte. Das ist zwar verständlich, aber deswegen nehme ich jedes "hab ich mal probiert, war aber blöd" mit einem Körnchen vorsicht.

Ich habe mich zusammen mit Dirty Oerti einen Tag hingesetzt und wir haben versucht einen git-Service hier an den Start zu bekommen.
Einen Tag mit Skripten und zusätzlichen Linux-Usern, die Rechte auf einem Server brauchten, der durchgehend im Internet hängt, der hostet und für dessen Verhalten (und Inhalt) ich gerade stehe.
Und nachdem wir am Ende des Tages immernoch nichts soweit klar hatten, dass es sinnvoll funktioniert, was ich mit einem einfachen "svnserve -d" hinbekomme, habe ich die Sache abgebrochen.
git über ssh ist nicht akzeptabel. Wenn Du was anderes weißt und eine akzeptable Anleitung hast - ich bin interessiert.

Wenn ich eine entsprechende Anleitung hier im Wiki habe, setze ich mich gerne und aus eigenem Interesse nochmal ran. Wir haben damals schon Anleitungen gesucht und uns daran gehalten.
Auf der MeetingC++ unterhielt ich mich mit anderen Entwicklern und wir besprachen auch Infrasturktur-Fragen. Eine Firma nutzt intern auch Git. Das hat mich interessiert.
Natürlich nutzen sie nicht github, sie haben sich eine komplette Github Installation eingerichtet. Der Spaß hat nur 1000 Euro an Lizenzkosten gekostet und läuft super.

Du zahlst die 1000 Euro und ich richte hier github.proggen.org ein. Deal?
Oder wir bekommen das so hin. Oder ich biete an, was ich kann. Ich kann Subversion anbieten.

Es ist wahr, ich bin kein SVN-Profi, aber ich habe auch damit gearbeitet. Es ist um ein vielfaches langsamer, ich finde die Zugrundeliegende "Vorstellung" von Versionsverwaltung ist kaputt, und bei komplizierteren merges wirds bald mal haarig.

Auschecken und ein Commit ist nicht damit gearbeitet. Zum normalen Ablauf gehört durchaus auch mal einen Branch anlegen, wenn man Dinge entwickelt, die haarig sein könnten. Das entspricht quasi einem Clone.

Und was sind komplizierte Merges!? Konflikte sind notwendig, wenn der Computer nicht entscheiden kann, wie hier richtig gemergt werden muss. 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.

git kann mehr als svn - unbestritten. Aber svn funktioniert auch sehr gut. Und nicht alles auf diesem Planeten ist OpenSource. Ich bin gerne bereit mich mit git weiter auseinander zu setzen, aber ich will nicht eine Woche brauchen, bevor ich einen auf proggen.org rechtlich vertretbaren Service einrichten kann. Schon gar nicht, wenn ich das mit svn in 5 Minuten kann. Dann ist git nämlich nicht die Lösung für mein Problem.


Ich habe jetzt nochmal kurz gegooglet und den git daemon gefunden. Vielleicht fand ich damals auch, vielleicht nicht!? Kann der Nutzerrechte abbilden? Vielleicht kommen wir damit ja ins Geschäft. Gitosis ist keine Option.

[fat-lobyte]

Ich habe mich zusammen mit Dirty Oerti einen Tag hingesetzt und wir haben versucht einen git-Service hier an den Start zu bekommen.
Einen Tag mit Skripten und zusätzlichen Linux-Usern, die Rechte auf einem Server brauchten, der durchgehend im Internet hängt, der hostet und für dessen Verhalten (und Inhalt) ich gerade stehe.
Und nachdem wir am Ende des Tages immernoch nichts soweit klar hatten, dass es sinnvoll funktioniert, was ich mit einem einfachen "svnserve -d" hinbekomme, habe ich die Sache abgebrochen.

Ok, kann ich verstehen.

Auschecken und ein Commit ist nicht damit gearbeitet. Zum normalen Ablauf gehört durchaus auch mal einen Branch anlegen, wenn man Dinge entwickelt, die haarig sein könnten.

Ja, auch das habe ich gemacht.

Das entspricht quasi einem Clone.

Das ist Teil des Problems, dass ein "branch" einem "clone" entspricht. Aber ich schweife ab.

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. Vielleicht sollte man noch dazu sagen, dass git nicht nur auf eine Weise, sondern auf mehrere Arten

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.

Musste man bei SVN nicht für merges irgendwie an den komischen properties manipulieren?

Ich habe jetzt nochmal kurz gegooglet und den git daemon gefunden. Vielleicht fand ich damals auch, vielleicht nicht!? Kann der Nutzerrechte abbilden?

Git-Daemon kann gar nix außer Repositories "mal schnell" als read-only zu veröffentlichen. Das ist nicht die Lösung.

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.

Alles andere geht irgendwie über WebDAV, aber so weit habe ich ehrlichgesagt nie getrieben.

ps.: Kleiner Bookmark für mich selbst: http://sourcevirtues.wordpress.com/2012 ... an-stable/

[Xin]

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.

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... ^^

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.

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.

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!?

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.

Alles andere geht irgendwie über WebDAV, aber so weit habe ich ehrlichgesagt nie getrieben.

ps.: Kleiner Bookmark für mich selbst: http://sourcevirtues.wordpress.com/2012 ... an-stable/

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.