Versionskontrollsorgen // Ich nehme "Sein eigenes Bitbucket sein wollen und an der Auswahl scheitern" für 500.

C

CrimsonKing

Guest
Da wir hier gerade so schön über Programmierthemen geredet haben, möchte ich mal ein Fass reinwerfen, das mit Sprachen nichts zu tun hat und hier schon von @rubricanis und im April mir aufgemacht wurde:

Wohin mit dem Code?

Bei mir hat sich über inzwischen 15 Jahre (vorher habe ich meine Software lieber niemandem gezeigt :)) ein gewisser Wildwuchs an Repositorys angesammelt. Ich bin Teil mindestens (ich müsste selbst nachsehen) zweier Projekte auf SourceForge, von denen eines immer noch aktiv entwickelt wird, ich habe ein kleines (eher privates) Projektlein auf Darcshub, den Großteil meiner Software hoste ich derzeit auf Bitbucket und eine Handvoll Code liegt immer noch bei GitHub herum, entweder aus Kompatibilitätsgründen (Einbindung in MELPA, Package Control usw.) oder weil er mir nicht wichtig genug ist.

Weil das natürlich ein suboptimaler Zustand ist und ich inzwischen genug virtuelle Server betreibe, die sich eigentlich - mit der altbekannten Ausnahme dieses einen Servers, dessen Migration in sehr behäbigen Schüben erfolgt - platz- wie RAM-mäßig sozusagen die Eier kraulen, würde es sich theoretisch anbieten, mein eigener Repositoryhoster zu sein. Geplant hatte ich das schon länger, aber die Arbeit, die Arbeit...

Ich habe mir jetzt mal die Zeit genommen und mich mit den derzeit einigermaßen aktiv weiterentwickelten Systemen auseinandergesetzt. Grundsätzlich: Wenn devel/pijul mit dem Nest irgendwann ausgereift ist, also ersteres unter Windows vernünftig funktioniert und letzteres endlich zum Download verfüg- und nicht nur im Browser anguckbar ist, dann ist es vermutlich genau das, was ich brauche, nämlich ein Darcs ohne Skalierungsprobleme und mit 'nem brauchbaren Webclient für die, die keine Kommandozeilen mögen. Das kann aber vermutlich noch ein bisschen dauern. Ein Ticketsystem wäre ja optional, ein Mantis kriege ich schon noch installiert.

Mein Entscheidungsproblem liegt im Spagat zwischen "ich will meinen Code hosten" und "andere Entwickler sollten auch was beitragen können". Bislang war mir das egal, aber eins meiner Projekte ist inzwischen doch recht bekannt - und eine Reihe an willkommenen Patches, die da eingetrudelt sind, hätte ich wohl nicht bekommen, wenn der Code nicht auf Bitbucket gehostet wäre. Andererseits habe ich auch schon Diffs für andere Projekte im IRC erhalten, die bloße Möglichkeit zu Pull-Requests (GitHub, Bitbucket) scheint also keine sonst vorhandene Hürde abzuräumen. Nach langer Überlegung habe ich daher beschlossen, diejenigen Repositorys, die nicht aufgrund anderer Leute Bequemlichkeit bei GitHub liegen müssen, auf meinen Server umzuziehen.

Aber wie?

Klar ist: Ein Spiegel auf GitHub, Bitbucket, GitLab oder so wird sinnvoll sein, erstens als dezentrale Sicherheitskopie, falls ich mal wieder den Server kaputt bekomme, zweitens, damit die Patches nicht versiegen. Selbst OpenBSD kopiert ja parallel "for public consumption" auf GitHub. Das sollte mit einem Cronjob aber grundsätzlich immer gehen und ist nicht vom gewählten VCS abhängig, hilft mir also überhaupt nicht bei der Entscheidungsfindung.

Was ich gern hätte, ist ein ohne Schmerzen [1] selbsthostbares VCS, für das es eine vernünftige Weboberfläche [2] gibt und dessen Funktionen nicht zu einem Großteil dem Zweck dienen, die Fehler, die sich bei der Benutzung des VCSs fast schon planmäßig ergeben, wieder auszubügeln [3]. Man sollte meinen, das sei nicht zu viel verlangt - aber gerade die "großen" Systeme machen's falsch:
  • [1] Mercurial spült einem erst mal eine halbe Linuxdistribution voller Pythongedöns auf den Server, die leider bemerkenswert gute Weboberfläche Kallithea übernimmt die zweite Hälfte. Erfahrungsgemäß bricht so was alle paar Wochen mal wegen irgendwelcher Abhängigkeiten zusammen. In einem ersten Anlauf habe ich nicht mal die Installation aus der Anleitung bis zum Ende hinbekommen. Schade!
  • [2] Darcs, das zwar eigentlich nicht "groß" ist, aber von dem ich gelegentlich mal schwärme, hat keine vernünftige Weboberfläche. Darcshub ist auf Smartphones nur sehr anstrengend benutzbar und auf dem Desktop auch alles andere als übersichtlich. Für mich privat kein Problem, aber... :rolleyes:
  • [3] Git, all den sonstwie tollen Tools aus seinem "Ökosystem" zum Trotz, mochte ich nie so wirklich, und je mehr ich ihm im Alltag begegne, desto schlechter wird mein Eindruck davon. Da wird, ganz GNU/Linux-typisch, einfach nur Funktion auf Funktion gestapelt und intuitive Bedienung ist Fehlanzeige. Ohne ständiges Handbuchlesen kommt man da nicht weit und GUI-Bedienung ist nicht immer eine Option.
Das lässt mir momentan zwei oder drei Optionen:
  1. BitKeeper. Habe ich nie benutzt, hat aber angeblich auch ein Webinterface. Natürlich ist bkbits.net seit Tagen nicht erreichbar, so dass ich bisher keine Möglichkeit hatte, es mir anzugucken, ohne gleich irgendwelche Installationen vorzunehmen. (Hat hier wer Erfahrung damit? Auf dem Papier sieht es ziemlich dufte aus.)
  2. SVN. Ich mag SVN und meine Projekte sind eh' alle eher Cathedral als Bazaar. Der offensichtliche Vorteil: Das dürfte eine sehr niedrige Hürde für mögliche Kollaborateure sein (könnte mir vielleicht sogar doch eine Spiegelung ersparen?) und es hat nicht fast nur Funktionen, die ich niemals benutzen werde. Der offensichtliche Nachteil: Das wird wieder zu einer Installationsorgie werden. Subversion (mit eigenem Benutzer natürlich), Mantis und eine vernünftige Weboberfläche für die Repositorys, wobei ich mich noch zwischen ViewVC (schon wieder Python :rolleyes:) und etwas komfortableren Alternativen entscheiden müsste.
  3. Fossil. Hat ein eingebautes Ticketsystem und jedes Repository kommt komplett in einer einzigen Datei daher (perfekt für Backups), aber die Weboberfläche gefällt mir irgendwie nur zum Teil. Die --repo-list - ich habe halt nicht nur eins - regt mich auf mit ihrer fehlenden Flexibilität, Syntaxhighlighting gibt's nicht und die Kombination "Fossil mit mehreren Benutzern und Repositorys hinter nginx mit SSL und eigener Subdomain" scheint angesichts der Dokumentationslage mit "exotisch" noch vorsichtig beschrieben zu sein.
Das ist doch alles zum Weinen.
 
Ich selber komme gut mit git klar und würde dir deshalb gitea empfehlen

"Ich kann Git aus diversen Gründen nicht ausstehen."
"Hier ist trotzdem ein Git-Tool für dich: ..."

Das ist übrigens einer der Gründe, warum ich Git nicht mag: Ihr nervt. :rolleyes:
(Falls sich aber hier sonst noch wer für so was interessiert: stagit ist ein saugeiles Stück Software bemerkenswert guter "Repository-Browser", kann ich Gitnutzern nur wärmstens ans Herz legen.)

Hast du dir mal Redmine angesehen?

Ja, damit musste ich bereits beruflich zu tun haben und habe es aktuell in einem anderen Kontext an der Backe. Ich hatte die Integration von Code aber, ehrlich gesagt, gar nicht wahrgenommen. Ich habe das immer nur als vergleichsweise unübersichtliches Mantis benutzen "dürfen". Dass man es direkt an Repositorys anbinden kann, ist gerade eine völlig neue Welt für mich. Darcs kann es leider nicht, aber SVN - damit hat sich ViewVC auf jeden Fall schon mal erledigt... :o danke!
 
Andererseits habe ich auch schon Diffs für andere Projekte im IRC erhalten, die bloße Möglichkeit zu Pull-Requests (GitHub, Bitbucket) scheint also keine sonst vorhandene Hürde abzuräumen.

Wieviele Leute sich aufgrund dessen erst gar nicht die Mühe gemacht?

Aus Sicht eines Außenstehenden: mit jeder Versionsverwaltung außer git und mercurial signalisiert du erstmal - unabhängig vom Wahrheitsgehalt - die Botschaft, dass du entweder nicht zeitgemäß arbeitest (SVN) oder durch Wahl einer nischigen Plattform nicht wirklich an Kooperation interessiert bist. Keine gute Voraussetzung für externe Beiträge.

Von mangelnder Integration in die gängigen Tools (IDEs, Continuous-Integration-Server etc.) ganz zu schweigen.

Mercurial spült einem erst mal eine halbe Linuxdistribution voller Pythongedöns auf den Server, die leider bemerkenswert gute Weboberfläche Kallithea übernimmt die zweite Hälfte. Erfahrungsgemäß bricht so was alle paar Wochen mal wegen irgendwelcher Abhängigkeiten zusammen. In einem ersten Anlauf habe ich nicht mal die Installation aus der Anleitung bis zum Ende hinbekommen. Schade!

Ist vielleicht das eingesetze Paketmanagement deinen Anforderungen nicht gewachsen? :confused:
Mercurial zu installieren und aktuell zu halten ist eigentlich kein Hexenwerk, das kriegt sogar Ubuntu gebacken. ;)
 
Nach meinem aktuellen Stand hat SVN immer noch mehr Nutzer als Git, gerade im Firmenumfeld...? Ich setze auf dem Server pkgsrc ein, ein paar Abhängigkeiten braucht Kallithea trotzdem. (Und ich sagte ja schon, ich sei willens zur Spiegelung auf Github, wenn das alles ist. ;))

Und ich habe gitea vorgeschlagen, weil es sich mit pkg install gitea installieren lässt

Das tun aber auch die genannten Alternativen...
 
Git wird mittlerweile sogar von Microsoft für Windows eingesetzt. In meinem Firmen Umfeld geht ohne git nichts mehr. Das Entwicklungsmodell mit Master und develop ist Standard und bringt viele Vorteile.

Falls du es einfach nicht magst, nimm mercurial. Das hat auch die meisten Vorteile von git.


https://m.heise.de/developer/meldun...fort-Git-zur-Windows-Entwicklung-3810273.html


Gute Hinweise gibt auch Google Trends

https://trends.google.com/trends/ex.../m/08441_,/m/08w6d6,/m/09d6g&hl=en-US&tz=&tz=
 
Was Microsoft macht oder nicht macht, interessiert mich für meinen Privatkram nicht im Geringsten.

Zu Mercurial: Ich bin ja absichtlich bei Bitbucket. Aber diese Dependency Hell von Python ängstigt mich sehr. Ich nutze privat eine Software, die auf aiohttp aufsetzt und alle paar Wochen nicht mehr funktioniert. :(
 
Also ich habe privat Mercurial und kann deine Dependency Probleme nicht nachvollziehen. Ist da vielleicht etwas mit der DB deines Packetmanagers im argen? Weder auf FreeBSD noch auf der Fedora Workstation gab es in den letzten Jahren Probleme damit. Zur Not gäbs immer noch Dockerimages..
 
Nö, ich kann mir schon vorstellen, dass das völlig korrekt so ist, es hängt halt nur eine Menge dran:

Code:
$ pfexec pkgin sfd mercurial
full dependency tree for mercurial-4.6.1
        libiconv>=1.9.1nb4
        pkg_install-info-[0-9]*
        ncurses>=6.0
        py27-curses-[0-9]*
        zlib>=1.2.3
        openssl>=1.0.2gnb1
        mozilla-rootcerts>=1.0.20150804nb1
        libffi>=3.0.11
        gettext-lib>=0.18
        db4>=4.8.30
        bzip2>=1.0.3
        python27>=2.7.1nb2
        py27-mercurial>=4.6.1
        gcc49-libs>=4.9.1

Und Kallithea obendrauf:

Code:
requirements = [
    "alembic >= 0.8.0, < 1.1",
    "gearbox < 1",
    "waitress >= 0.8.8, < 1.2",
    "WebOb >= 1.7, < 1.8", # turbogears2 2.3.12 requires WebOb<1.8.0
    "backlash >= 0.1.2, < 1",
    "TurboGears2 >= 2.3.10, < 3",
    "tgext.routes >= 0.2.0, < 1",
    "Beaker >= 1.7.0, < 2",
    "WebHelpers >= 1.3, < 1.4",
    "FormEncode >= 1.2.4, < 1.4",
    "SQLAlchemy >= 1.1, < 1.3",
    "Mako >= 0.9.0, < 1.1",
    "Pygments >= 1.5, < 2.3",
    "Whoosh >= 2.5.0, < 2.8",
    "celery >= 3.1, < 4.0", # celery 4 doesn't work
    "Babel >= 0.9.6, < 2.7",
    "python-dateutil >= 1.5.0, < 2.8",
    "Markdown >= 2.2.1, < 2.7",
    "docutils >= 0.8.1, < 0.15",
    "URLObject >= 2.3.4, < 2.5",
    "Routes >= 1.13, < 2",
    "dulwich >= 0.14.1, < 0.20",
    "mercurial >= 4.1.1, < 4.8",
    "decorator >= 3.3.2, < 4.4",
    "Paste >= 2.0.3, < 3",
]

Da vergeht's einem ein bisschen.
 
Da Kallithea irgendwo zwischendrin mit den üblichen skurrilen Python-"Fehler""meldungen" aussteigt, sind es wohl vor allem Kallithea zu viele Abhängigkeiten... und werd den Mist mal los, wenn du nicht mitgeschrieben hast, was alles dabei war. Grmpf.
 
Oder von hier: "pkg info -r pkgname shows everything that requires pkgname. -d is the opposite, showing everything that pkgname depends on."

PS: Und nach wie vor kann man gitea mit einer einzelnen Binärdatei zum Laufen bringen :D
 

Funktioniert im zweiten Fall nicht, ist pip.

Versteht mich nicht falsch, bei der Wahl zwischen Git und Mercurial greife ich mit einem freudigen Lächeln zu Mercurial. (Netter Versuch, @zuglufttier. :D Aber das bietet Fossil auch... und da ist dann sogar das Repository drin.) Aber in diesem Fall kann ich auf das "D" in "DVCS", vermutlich der einzige technische Marktvorteil beider Systeme, getrost verzichten.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben