webEdition und github

[Paladin]

Hi, da webEdition ja "open" ist, gibt es Pläne das Projekt nach github zu migrieren?
Im Prinzip könnte man so als "Außenstehender" besser sein Beiträge einbringen und am Projekt aktiv mitmachen.
Ich schmeiße es mal als FR in die Runde

[ThomasGoebe]

Wir sind im Moment bei Sourceforge, was spricht dagegen, dort mitzumachen?

[OT]
Und: webEdition ist (zumindest in der Theorie) Managed Open Source. D.h. es soll nicht jeder einfach das rein setzen, was er/sie gerade will sondern es soll abgesprochen und geplant werden. Zugegeben, in der Praxis passiert diese Planung bei vielen Kleinigkeiten im Moment nicht, aber die Entwicklerzahl ist noch so überschaubar, dass es nur selten dadurch Probleme gibt.

Wenn es mehr Entwickler werden, dann wird es eine deutliche Verbesserung in der Zuweisung und Strukturierung von Punkten im Mantis geben müssen.
[/OT]

[Paladin]

Und: webEdition ist (zumindest in der Theorie) Managed Open Source. D.h. es soll nicht jeder einfach das rein setzen, was er/sie gerade will sondern es soll abgesprochen und geplant werden.

Mal nebenbei: Genauso passiert es auf github, aber: Man hat den Vorteil, dass man ohne große hindernisse mitmachen kann (repo clonen, was ändern) und das dann als "pull request" dem "owner" vorschlagen (!) kann. Dieser kann dann selbst entscheiden, ob es reinkommt oder nicht.
Zusätzliche Vorteile sind der integrierte "Issue Tracker", bei dem du bis auf Zeilenebene markieren kannst, was schief geht - wenn du willst, funktioniert das Ding aber auch "nur" so wie Mantis.
Am besten mal testen, Sourceforge ist eher behäbig, was das angeht ... und es ist ja leider immer noch SVN ;(

[WBTMagnum]

Hi,

Ich habe mich auch schon öfters gefragt, ob eine Umstellung auf Github, Bitbucket oder ein anderes äquivalentes System dem Projekt nicht gut tun würde. Mit Mantis selbst finde ich kann man schon gut arbeiten. SVN und Sourceforge im Speziellen sind allerdings eine echt Krücke geworden. So ist z.B. die Suche nach einzelnen Changesets oder einfach nur das Einsehen des Revision Logs über das Webinterface extrem zeitintensiv. Da sind potentiell interessierte Entwickler weg bevor sie sich überhaupt eingearbeitet haben. Auf die Vorteile moderne DVCS wie git und hg glaube ich brauche ich hier nicht eingehen.

Der Aufwand ist hier sicher das Hauptargument gegen eine Umstellung. Das macht man in der Regel aber auch nur ein mal und das amortisiert sich dann recht schnell.


Just my 2 cents,
Sascha

[Paladin]

Der Aufwand ist hier sicher das Hauptargument gegen eine Umstellung. Das macht man in der Regel aber auch nur ein mal und das amortisiert sich dann recht schnell.

Als Aufwand meinst du den Aufruf von 'git-svn' mit ein paar parametern? Sry, aber auch ich hab schon ein 4 Jahre altes 3 GB Projekt konvertiert, hat genau eine Kaffeelänge gedauert, dannach ein push und am nächsten Morgen war alles fertig. Ich sehe da kein Argument!

Ich bin ja privat auch eher der bitbucket fan, aber webEdition soll ja "public" sein, und das würde bei bitbucket ja kosten Bleibt also erstmal nur github, weil kostenfrei ist.

Repos durchsuchen mit git ist ja ein traum, vor allem, wenn du mal nicht online bist
Ne, wir kennen alle die "svn vs git" argumente, keine Frage.
Leute, "time to change"

[WBTMagnum]

@Aufwand:
Klar, die Konvertierung eines Repos geht halbwegs schnell. Du darfst aber nicht vergessen, dass da in der Regel auch andere Infrastruktur (z.B. Update Server), Build Scripts, div. Workflows, etc. dran hängen können. Das will dann schon ordentlich geplant sein .

LG,
Sascha

[ThomasGoebe]

Es ist tatsächlich so, dass der Updateserver etc. ja auch darauf zugreifen. Auch die einzelnen Entwickler müssen bei sich umstellen. Im Einzelnen sind das sicher kleine Hürden, in der Summe aber nicht ohne.

Es gibt also kein generelles dagegen sein, nur tatsächlich eine Frage des Aufwands (und auch der Relation Aufwand / Nutzen)

@Paladin: Wenn Du diese Umstellung gerne begleiten möchtest, dann freue ich mich über ein Konzept für das Vorgehen, welches Ausfälle verhindert (auf ein Minimum reduziert) und in dem auch die wirklichen Vorteile gegenüber der jetzigen Lösung aufgezeigt sind. Wir können jede Hilfe gebrauchen. Wenn unser Entwicklungsleiter das ganze dann geprüft hat, könnten wir sicher umstellen. Bei Fragen zu aktuellen Abhängigkeiten (Nightly Builder, OnlineInstaller, LiveUpdate) steht sicher Armin per E-Mail zur Verfügung.
Vom Mantis auf Github umzustellen ist übrigens auch nicht mal eben gemacht. U.a. nutzen wir derzeit definierte Exporte, um die Versionshistorie möglichst automatisiert zu erzeugen.

Ursprünglich wollten wir das svn-repo eigentlich auf unserem eigenen Server betreiben, aktuell haben wir das aber auch auf Eis gelegt.

[mokraemer]

@Paladin:
wir sind aktuell bei svn - ich würde hg gegenüber git präferieren. bei sourceforge gibt es im übrigen alle 3 kostenfrei - würde also erst mal nix dagegen sprechen bei sourceforge zu bleiben.

Der Vorteil von den verteilten Versionskontrollen wäre nur das man lokale commits machen kann - ansich ist genau das was wir nicht wollen.
Die verteilten setzen auch viel mehr darauf das es einen Review Prozess mit Integration etc. gibt. Dazu sind derzeit zu wenige Entwickler da.
Im übrigen könnte man auch vieles bereits so in svn umsetzen. Git hat nur einfach mal einen Hype erfahren und jetzt stürzt sich jeder drauf, dabei merkt man dem Tool durchaus an, das es auf den Workflow zur Kernelentwicklung optimiert ist.

Ich sehe bei git/hg im Entwicklungsablauf (für uns) keinen Vorteil gegenüber svn. Und wie Thomas richtig sagte, müßte dann u.a. auch der Updateserver angepaßt werden.
Das es für Außenstehende eine Hürde ist/wäre glaube ich nicht. Wir akzeptieren ja auch Patches - also völlig ohne Versionskontrolle - aber sowas wird äußerst selten eingereicht. Dazu braucht man entweder das Tar-Ball oder holt sich den Lesezugriff aufs svn.

Mantis sollte auf keinen Fall ersetzt werden. Sourceforge hätte auch einen BugTracker - aber daraus entstehen auch nicht weniger Bugs nur weil es einen anderen Tracker gibt.

@Changesets/commits: die sind ja auch nur teilweise für die Öffentlichkeit bestimmt - und wenn man die wirklich ansehen will, dann schmeißt man eben mal ein "svn log" auf den freien Lesezugang von WE an.
Alles wichtige dokumentieren wir im BugTracker und auch in den Release-Notes.

[WBTMagnum]

Der Vorteil von den verteilten Versionskontrollen wäre nur das man lokale commits machen kann - ansich ist genau das was wir nicht wollen.

Das ist wohl kaum der einzige Vorteil.

• DVCS erlauben den EntwicklerInnen schnell zwischen einzelnen Versionen oder Entwicklungszweigen zu wechseln - auch offline!
• Gerade lokale Commits können von immensem Vorteil sein. So kann in Ruhe an Features gearbeitet werden und diese Änderungen können anschließend in einem abgeschlossenen Paket wieder zurück gespielt werden.
• Forking!!! Use the fork luke!

Ich wollte aber eigentlich nicht darüber diskutieren .

Die verteilten setzen auch viel mehr darauf das es einen Review Prozess mit Integration etc. gibt. Dazu sind derzeit zu wenige Entwickler da.

Das kommt darauf an wie die Workflows definiert bzw. gelebt werden und hängt weniger vom VCS ab. HG und GIT bieten für solche Workflows aber sicherlich das bessere Toolset.

Das es für Außenstehende eine Hürde ist/wäre glaube ich nicht. Wir akzeptieren ja auch Patches - also völlig ohne Versionskontrolle - aber sowas wird äußerst selten eingereicht.

<zynismus-mode=on>Was könnte der Grund dafür sein, dass EntwicklerInnen keine Patches einreichen *hmmm*. Vielleicht gibt es ja doch eine Hürde .... <zynismus-mode=off> *sorry*

Für mein Gefühl ist es deutlich einfacher ein Projekt zu Forken, etwas zu ändern/korrigieren und dann einen Pull Request abzusenden. Bei einem Patch muss man dann schon wieder wissen an wen ich diesen senden kann/soll. Ganz ehrlich: Ich habe schon oft überlegt einfach nur einen HG-Server als Mirror zum SVN-Repo zu erstellen um hier effizienter arbeiten zu können. Ich mach zwar immer nur Kleinigkeiten, die sollen dann aber schnell gehen .

Mantis sollte auf keinen Fall ersetzt werden. Sourceforge hätte auch einen BugTracker - aber daraus entstehen auch nicht weniger Bugs nur weil es einen anderen Tracker gibt.

Eine gute Verknüpfung zwischen BugTracker und VCS, und somit eine gute Nachvollziehbarkeit sind hier meiner Ansicht nach der Knackpunkt. Ein starkes Duo kann die EntwicklerInnen und auch normale User enorm unterstützen. Die Anzahl der Bugreport kann wohl kaum als Kriterium für oder gegen ein BugTracking System herangezogen werden.

@Changesets/commits: die sind ja auch nur teilweise für die Öffentlichkeit bestimmt - und wenn man die wirklich ansehen will, dann schmeißt man eben mal ein "svn log" auf den freien Lesezugang von WE an.Alles wichtige dokumentieren wir im BugTracker und auch in den Release-Notes.

Warum sollten changesets/commits nicht für die Öffentlichkeit bestimmt sein? Wenn ich als Entwickler Probleme Debugge, dann interessiert mich das sehr wohl und ein niederschwelliger Zugang erleichtert mir hier die Arbeit. Ein offener Umgang mit dem Code ist hier meiner Ansicht nach essentiell. Die Release History für die User und Kunden braucht es natürlich auch, die spricht aber eine ganz andere Zielgruppe an.


Just my 2 cents,
Sascha

[Paladin]

Stimme dem letzten Post meines Echtnamensvettern Sascha voll und ganz zu!

Was könnte wohl der Grund für wenig "contributions" sein? Meist ist es die fehlende oder mangelnde Standart-Unterstützung ... zumindest in meinen nun fast 14 Jahren als Entwickler war das immer so.

git=hype: Dachte ich auch zuerst. Ich habe in meiner aktuellen Arbeit auch über 60 SVN Repos (Kundenprojekte, nur die aktiven) und habe mich lang gegen git gesperrt, ähnliche "Argumentation" wie oben. Nun sitze ich im Homeoffice und merke an meinen privatprojekten, dass ich mit git schneller und effektiver arbeiten kann wie mit SVN. Allein mal ein großes Repo in der History zu durchsuchen und dann ein switch können bei SVN echt nervend sein, bei git bleibt dir nicht mal Zeit für ein Nippen am Kaffee

Standarts: git mit seinem pull-request ist wohl die einfachste Art, seine Verbesserung einzureichen, so minimal wie sie auch sein mag. git und github kann man eh kaum trennen und es gehört ja schon fast zum guten Ton bei einer Bewerbung, ein aktives github-Konto vorweisen zu können.

nur lokale commits als vorteil: evtl. nochmal nachlesen, wo sich SVN und git _wirklich_ unterscheiden, auf den ersten Blick scheint das alles zu sein. Wer allerdings mal länger mit git gearbeitet hat merkt schnell, dass er nicht mehr zu SVN zurück möchte.

SF kann das auch: Ja, aber wie, ist echt ein trauerspiel bei sf. Und mal ehrlich: Ist webEdition nun OPEN oder nicht? Commits zu verbergen kann nicht der Weg sein, wenn man ein System verbessern möchte. Ein System wird nicht besser, weil du es dir besser vorstellst. Du wirst nicht besser, nur weil du kritisch in den Spiegel schaust. Sei ehrlich: Du wächst nur an deinen "Gegnern", an Entwicklern um dich rum, die besser sind wie du. Und die solltest du suchen. Es ist nicht schlimm, Fehler zu machen, es ist nur schlimm, daraus nicht zu lernen (oder lernen zu wollen!).

Integration: Ehrlich Leute: Ein Zugang fürs Forum, einer für das QA, einer für SVN... wie 2002 ist das denn bitte? EIN Login bei github und fertig für alles, ein Issue mit verweis zur Datei und Zeilennummer und ein Commit mit "fix:#3298 blahblah" und das Ding ist fertig. Ich weiß echt nicht, wie man dagegen sein kann.

Umlernen: Echt leute, git habt ihr in 15 Minuten raus, wenn ihr SVN könnt. aus "svn commit" wird "git commit" und so weiter. Es geht nur schneller.

Update-Server: Ich denk mal, dass es nicht soo lange dauert, einen Updateserver umzustellen.

Infrastruktur: Müsste man kennen lernen, wie das bei euch en detail aufgebaut ist. Einen Weg gibt es immer. Und der führt am besten in die Flexibilität

Schlußendlich: Es war ja nur ne Frage, alle erfolgreichen Projekte der letzten Zeit, die ich kenne, basieren auf github, eben _weil_ es da so einfach ist mitzumachen. Plötzlich kommen Patches und pull-request von Leuten von denen du nie-nie-nie vorher gehört hast. Und *zack* wieder 8 Issues fixed. Hat man dann noch entsprechend automatisierte Tests reicht ein klick, ein Schluck kaffee, wenn passt, dann übernehmen. Der "Lohn" des Fremden: Er taucht als contributor im git-log auf! Den meisten reicht das und vor allem, dass das akute Problem des einzelnen nun gelöst ist.
Die Frage entstand, nachdem es für mich einen immensen Aufwand darstellt, auch nur nach dem Zugang zum SVN zu fragen, geschweige denn, den auch noch zu benutzen (wieder ein neuer Zugang, wie doof).

[ThomasGoebe]

Spannend! Wir haben hier eine Diskussion über Grundhaltungen und -einstellungen, die wir auf dem "Rücken" zweier Techniken führen.

Ich finde die Diskussion gut und richtig. Wie an anderen Stellen auch, halte ich es aus meiner 15 jährigen Erfahrung jedoch für sinnvoll, Anforderungen zu definieren und dann die passende Technik zu finden. Also die Entscheidung für eine Technik auf Basis der Anforderungen zu treffen und nicht, weil einem etwas (gerade) gefällt oder es schon immer so gewesen ist.

Nur weil es in dem einen System so einfach ist, zu "forken", muss das nicht der richtige Weg sein. Und nur, weil es in dem anderen System kein singleSignon gibt, muss das kein Nachteil sein.

Für mich persönlich was es bisher z.B. oft sinnvoller, jeweils einen Spezialisten (Forum, Bugtracker, SVN) zu nutzen, statt einen Alleinunternehmer (alles bei github). Mehrere Logins sind für mich da kein Problem.
Doch gerne lerne ich dazu. Wenn man in eine Diskussion geht, dann es nur erfolgreich sein, wenn beide "Seiten" bereit sind, die eigene Meinung zu überdenken. Sollte das nicht so sein, kann die Zeit anderweitig genutzt werden.

Eventuell wird aus dem A oder B dann auch ein C.

Warum nun so wenig Entwickler bei webEdition aktuell Patches einreichen, ist auf beiden Seiten eine Spekulation. Es gibt da außer den persönlichen Einstellungen und subjektiven Neigungen und Abneigungen schlicht keine aussagekräftigen Daten. Ich habe da auch eine Meinung zu und danach liegt es vor allem daran, dass webEdition lange kommerziell war und viele der Nutzer einfach nicht typische OpenSource Entwickler sondern höchstens Nutzer sind (ich gehöre auch zu dieser Gruppe). Das ist keine Kritik sondern einfach eine Feststellung.

Also: unabhängig von der Technik (git oder svn): was sind die Anforderungen an das Entwicklungssetup für webEdition ? Wie wird webEdition weiter entwickelt? Wie soll es weiter entwickelt werden?

Ich mache mir über diese Frage jetzt einmal ernsthaftere Gedanken als in zwei Minuten schnell mal gepostete Meinung und freue mich, wenn ihr euch dem anschließt und auch Eure Gedanken dazu äußert.

Auf jeden Fall schon einmal Danke für diese Anstoß. Spannend auch, dass es so lange dauert, bis so was kommuniziert wird. Auch eine interessante Beobachtung der webEdition Community.

[mokraemer]

Das ist wohl kaum der einzige Vorteil.
DVCS erlauben den EntwicklerInnen schnell zwischen einzelnen Versionen oder Entwicklungszweigen zu wechseln - auch offline!
Gerade lokale Commits können von immensem Vorteil sein. So kann in Ruhe an Features gearbeitet werden und diese Änderungen können anschließend in einem abgeschlossenen Paket wieder zurück gespielt werden.
Forking!!! Use the fork luke!

Das sind aber alles keine Sachen die zu unserem Workflow gehören. Wir haben 2 Zweige und viel mehr machen auch kaum Sinn.

SF kann das auch: Ja, aber wie, ist echt ein trauerspiel bei sf. Und mal ehrlich: Ist webEdition nun OPEN oder nicht? Commits zu verbergen kann nicht der Weg sein, wenn man ein System verbessern möchte. Ein System wird nicht besser, weil du es dir besser vorstellst. Du wirst nicht besser, nur weil du kritisch in den Spiegel schaust. Sei ehrlich: Du wächst nur an deinen "Gegnern", an Entwicklern um dich rum, die besser sind wie du. Und die solltest du suchen. Es ist nicht schlimm, Fehler zu machen, es ist nur schlimm, daraus nicht zu lernen (oder lernen zu wollen!).

Nein, so meinte ich das auch nicht. Es soll nichts verborgen werden. Nur liest da, außer dir, wahrscheinlich eh kaum einer mit.

Nun sitze ich im Homeoffice und merke an meinen privatprojekten, dass ich mit git schneller und effektiver arbeiten kann wie mit SVN. Allein mal ein großes Repo in der History zu durchsuchen und dann ein switch können bei SVN echt nervend sein, bei git bleibt dir nicht mal Zeit für ein Nippen am Kaffee

ja, kenne ich - auch das brauche ich bei svn eher selten. Sicherlich ist die Performance von svn schlechter - zum Großteil liegt das aber an sf und nicht am Tool selbst. Die Sachen die ich auf eigenen svn-Servern mache, sind deutlich schneller.
Ich habe auch schon mit git und hg gearbeitet. Bei CM2 hab ich auch regelmäßig Ärger damit. Meine Erfahrung ist, wenn an git/hg mal mehr wie einer arbeitet und auch länger kein push/pull macht, dann wird es ziemlich undurchsichtig.

Ansich wäre die Diskussion auf der letzten Konferenz gut angesiedelt gewesen, ggfs. ja abends beim Essen.
Aber ihr könnt euch ja erst mal über svn beteiligen und können danach dann entscheiden wie es weiter geht. Man sieht ja, wer in letzter Zeit comitted. Zuerst mal müssen die Leute die am meisten am System arbeiten gut mit den Tools zurecht kommen, sonst habt ihr das Gegenteil erreicht und es gibt keine comits mehr. In sofern muß der Mehrwert (über den ihr nicht diskutieren wollt) ersichtlich sein. Warum brauchen wir forks, warum wollen wir lokale commits (das unterstützt meine Toolchain bereits mit svn), warum brauchen wir branches zwischen denen ich schnell wechseln kann. In wie weit vereinfacht es mir damit schneller Bugs zu fixen, ....

[Paladin]

Ansich wäre die Diskussion auf der letzten Konferenz gut angesiedelt gewesen, ggfs. ja abends beim Essen.

Haben wir gemacht, wurde auf später vertagt bzw. auf einen Entwickler, der nicht da war oder später kam.
Alles in allen waren es die gleichen Argumente, allerdings mit wesentlich mehr Hintergundmusik.

Aber ihr könnt euch ja erst mal über svn beteiligen und können danach dann entscheiden wie es weiter geht. Man sieht ja, wer in letzter Zeit comitted.

Ich arbeite privat nicht mit SVN, daher keine commits meinerseits.

In sofern muß der Mehrwert (über den ihr nicht diskutieren wollt) ersichtlich sein. Warum brauchen wir forks, warum wollen wir lokale commits (das unterstützt meine Toolchain bereits mit svn), warum brauchen wir branches zwischen denen ich schnell wechseln kann. In wie weit vereinfacht es mir damit schneller Bugs zu fixen, ....

Okay, zuerst zum lokalen commiten in SVN: Das gibt es nicht. Wenn, dann commitest du zu deinem lokalen Server, aber: SVN kennt keine lokalen commits, commits an localhost sind keine lokalen commits, das sind nur pseudo-lokale commits.
Vereinfachen Bugs zu fixen: Ich habe einen Bug, ich forke, ich fixe, ich erstelle einen pull-request. Dein Job bis dahin: null, nur kurz mergen, fertig. Beim SVN? Frag dich selbst, wieviel du da machen musst. Merge mal komplexe Strukturen im SVN, wahrscheinlich mit vielen "conflicts", viel Spaß. Zwar schon besser wie CVS, aber mal ehrlich, warum, wenn es einfacher geht?
Warum branches? Weil es geht und du es mit SVN nicht korrekt nutzt. Punkt. Ja, großes Aufschreien, aber es ist wirklich wahr, bis vor 6 Monaten habe ich das auch nicht geglaubt. Fakt ist: _Richtig_ ist, einen "master,trunk oder release" branch zu haben, den haben die meisten. Richtig ist, einen "dev oder finaltest" branch zu haben, in dem die frischen Sachen liegen, die kurz vorm release sind, habt ihr auch. Richtig, auch mit SVN, wäre es nun, für jedes Feature oder jeden Bug erst zu branchen, das Feature/den Bug zu schreiben/zu erledigen und dann zurück zu mergen. Warum? Weil du branches besser stück für stück mergen kannst mit vielen Entwicklern als wenn 13 Entwickler auf einen Tag 13 Versionen von "trunk" oder "dev" hochladen. Merge mal mit SVN, viel Spaß
Erst-mal-zurechtkommen-push-vergessen: Sry, wer ein heutiges VCS nicht bedienen kann ... sicher habe ich bei git einen, EINEN Schritt mehr, das "push". Na und? Dafür kann ich 20 mal lokal commiten, und kurz vor dem Spätfilm im Kino einmal "push" mit Option zum runterfahren-nach-erledigt und gut ist. Bei SVN darfst du 20 mal commiten und warten, das kann u.U. nerven.

Zurück zum Sinn: Wo ist der Mehrwert, außer bei Schnelligkeit der lokalen commits und der Transparenz für viele Beteiligten, dem akzeptierten de-facto Standart von github als OPEN-Platform (ich kenn kaum noch aktuelle (!) Entwickler die gern bei SF sind und namenhafte OS schreiben) ? Wo ist der Mehrwert bei einem VCS, das nicht von einem einzelnen Backup abhängt und dessen Codebasis wesentlich jünger ist als SVN? Gibt wahrscheinlich keinen, wird es wahrscheinlich nie geben und gab es in Vergangenheit auch nie. Darum wechseln auch so viele von SVN zu git, weil es einfach keinen Sinn macht </ironie>
Nun, zumindest bei mir ist es so: Ich _würde_ gern, habe aber privat keine Zeit (da mache ich ja indirekt was mit dem we:test-projekt) und beruflich keine Kapazität zum "contributen" (außer das wir gold-partner sind). Allerdings hatte ich mal Zeit, da war mir die Hürde aber zu hoch ... ich glaub, den SVN zugang habe ich sogar noch ... irgendwo ... keine ahnung wo. Meine github Zugangsdaten wären dagegen verfügbar, da kann ich viele Projekte auf einmal ... auch das hatten wir alles schon.

Man könnte mit einem parallelbetrieb starten, irgendeine aktuelle we-version zu github hochladen und sowohl svn als auch git anbieten. Die core-leute könnten sich ja aussuchen, welches sie nehmen und normal weiterarbeiten, ab und an werden die Sachen von SVN zu git (oder anderherum) kopiert, damit die nicht zuweit auseinander gehen. Und dann schaut man mal, wohin die Reise geht, bzw. wieviele contributors man hat und welche Probleme die melden und haben.
Evtl. wird auch git gar nicht akzeptiert von den leuten, wer weiß, wer weiß.

[mokraemer]

Haben wir gemacht, wurde auf später vertagt bzw. auf einen Entwickler, der nicht da war oder später kam.
Alles in allen waren es die gleichen Argumente, allerdings mit wesentlich mehr Hintergundmusik.

Soweit ich mich erinnere haben wir am Tisch nur über die Unit-Tests von dir gesprochen.

Ich arbeite privat nicht mit SVN, daher keine commits meinerseits.

Mit der Einstellung kommen wir hier nicht weiter.

Vereinfachen Bugs zu fixen: Ich habe einen Bug, ich forke, ich fixe, ich erstelle einen pull-request. Dein Job bis dahin: null, nur kurz mergen, fertig. Beim SVN? Frag dich selbst, wieviel du da machen musst. Merge mal komplexe Strukturen im SVN, wahrscheinlich mit vielen "conflicts", viel Spaß. Zwar schon besser wie CVS, aber mal ehrlich, warum, wenn es einfacher geht?

ich forke nicht, weil ich es nicht brauche und comitte. Fertig.

Richtig, auch mit SVN, wäre es nun, für jedes Feature oder jeden Bug erst zu branchen, das Feature/den Bug zu schreiben/zu erledigen und dann zurück zu mergen. Warum? Weil du branches besser stück für stück mergen kannst mit vielen Entwicklern als wenn 13 Entwickler auf einen Tag 13 Versionen von "trunk" oder "dev" hochladen. Merge mal mit SVN, viel Spaß

Falsch: das ist ein Weg wie man arbeiten kann. Und den hast du für dich als richtig erachtet.

Man könnte mit einem parallelbetrieb starten, irgendeine aktuelle we-version zu github hochladen und sowohl svn als auch git anbieten.

Wenn du das machen willst, steht dir das frei.

[WBTMagnum]

Ich denke, so führt uns die Diskussion nicht weiter.

Wie Thomas richtig gesagt hat, muss das Environment sinnvolles Arbeiten für die aktiven Entwickler erlauben. Wenn SVN(+Mantis) das momentan tun, dann kann ich persönlich damit leben.

Nichtsdestotrotz halte ich es für sinnvoll dieses Thema im Auge zu behalten und die Für und Wider zu sammeln. Vielleicht schaffe ich es ja zu nächsten Konferenz, da können wir dann auch gerne weiter diskutieren - ev. auch in größerer Runde. Ich denke, dass hier auch ein Austausch über die verschiedenen Workflows und Arbeitsweisen sehr bereichernd sein kann.

LG,
Sascha