FreeBSD Ports migrieren am 14. Juli auf Subversion

[Yamagi]

Nur eine kurze Mitteilung: Die Port migrieren am 14. Juli von CVS auf SVN:

The FreeBSD ports tree will migrate from CVS to Subversion soon. The anticipated date for the migration is July 14th. This will have no impact for ports tree users as there will be a SVN to CVS exporter.
Please note that cvsup will still work after the migration. Nevertheless c(v)sup is pretty dated so you may want to see if portsnap(8) will fit your needs.
Beat and Thomas
 on behalf of portmgr@

[Fusselbär]

14. Juli, Sturm auf die Bastille? Revolution? Subversion!

[Kamikaze]

Hmm, seitdem ich Mercurial verwende habe ich für SVN nichts mehr übrig.

[Yamagi]

Und genau liegt doch einer großenb Vorteile von SVN. Man kann es in praktisch jedes VCS auschecken. Egal ob bzr, fossil, git, hg und die Eigenkreation, eine Brücke zu SVN gibt es (fast) immer. Wenn man hingegen im Upstream ein hg hat, zwingt man alle Downstream-Nutzer ebenfalls hg zu verwenden. Ob sie wollen oder nicht.

[oenone]

Subversion ist wirklich schlimm.. Frage mich, warum die sich das antun.

[Amin]

Ich benutze SVN sehr gerne. Kommt halt auf den Einsatzzweck an. The right tool for the job!
Mercurial ist für andere Anforderungen besser.

[Frank]

Wo liegen denn die Unterschiede Eurer Meinung nach
zwischen Subversion, Mecurial und Git?

[ath0]

Mercurial und git nehmen sich so weit ich weiß nichts. Subversion ist im gegensatz zu den anderen beiden Tools ein Zentrales cvs. Ich persönlich konnte mit SVN nie viel anfangen und bin zu doof es richtig zu benutzen, allerdings ist git für mich immer das richtige Tool. Einige Vorteile an git und Mercurial sind, dass die Repos kleiner sind als die von SVN (getestet mit den FreeBSD Sourcen) und dass die Aktionen wie checkout und commit schneller sind, was mit an der Netzwerk freuntlicheren übermittlung liegt.

Ich bevorzuge git, aber wenn das FreeBSD Projekt das so entscheidet dann ist mir SVN auch recht.

Gruß

ath0

[dettus]

also, ich benutze auf der arbeit (mehr oder weniger gezwungenermassen) svn.
und ich muss sagen dass ich es fuer das bessere cvs halte.

[Wotan]

Zitat von dettus

also, ich benutze auf der arbeit (mehr oder weniger gezwungenermassen) svn.
und ich muss sagen dass ich es fuer das bessere cvs halte.

Der Slogan von SVN war doch auch "CVS done right"

CVS sollte auch wirklich niemand mehr benutzen muessen. Ich halte das fuer eine sehr gute Entscheidung.

[Eisenfaust]

ich verstehe auch nicht so recht, wieso FreeBSD auf SVN setzt. Im Linux-Umfeld ist man weitaus innovativer. Hier verwechselt das BSD-Klientel "konservativ" mit "rückständig". Die Linux-Nutzer - ebenso große Unternehmen mit einer breiten Altlastenbasis, konnten ja auch auf GIT umsrüsten.

Ich nuzte SVN deshalb, weil ich synchron mit FreeBSD von CVS auf SVN umgestiegen bin. Es hätte auch anders sein können. Da ich lediglich für meine wiss. Arbeit Sofware entwickele, sind mir die feinen Unterschiede der Systeme nicht bekannt. ich weiß allerdings, daß mir SVN sehr oft für Kopfzerbrechen bezüglich inkosistenter Repositorien sorgt. Meine GIT-nutzenden Kollegen lächeln darüber nur.

Dennoch, ich finde es lobenswert, daß auch die Ports nun auf ein SVN umziehen.

Das erhebt allerdings die Frage, ob es denn dann auch die notwendigen Werkzeuge "an Bord" FreeBSDs geben wird, um ohne den devel/subversion Port an die Ports zu kommen.

Um die Quellen des Kernsystems auszuchecken, muß man nämlich Subversion installieren, wenn man einen versionierten Quellbaum via SVN in /usr/src haben will. Das ging anfangs auch nicht glatt und bedurfte einiger PRs, um gewisse Schlampigkeiten aus dem Weg zu räumen ...

[Kamikaze]

Zitat von Yamagi

Und genau liegt doch einer großenb Vorteile von SVN. Man kann es in praktisch jedes VCS auschecken. Egal ob bzr, fossil, git, hg und die Eigenkreation, eine Brücke zu SVN gibt es (fast) immer. Wenn man hingegen im Upstream ein hg hat, zwingt man alle Downstream-Nutzer ebenfalls hg zu verwenden. Ob sie wollen oder nicht.

Aber SVN hat nicht das Feature-Set eines DVCS. Spätestens bei komplexen Merges, die mit einem DVCS ziemlich problemlos gehen, hat man mit SVN immer noch den gleichen Ärger wie mit CVS.

[Yamagi]

Ich habe lange überlegt, ob ich hier überhaupt noch etwas schreiben soll. VCS sind ein religiöses Thema und neigen daher zu Streit. Aber nun mache ich es... Für das FreeBSD-Projekt sieht es halt (von außen gesehen) so aus, dass man eines der letzten großen Projekte ist, die noch CVS nutzen. Und das Ports-Repo dürfte eines der größten CVS-Repos überhaupt sein. Das man mit der Migration solange gewartet hat, bedeutet ja im Prinzip, dass man damit sehr lange zufrieden war. Die Hauptprobleme von CVS sind technischer Natur. Es skaliert vergleichsweise schlecht, atomare Commits sind etwas, was man im jahr 2012 haben will und Repocopys sind irgendwie so 90er. Wieso also nun das Rad neu erfinden? SVN ist genau für diesen Fall gedacht, es soll ein besseres CVS sein. Nicht mehr und nicht weniger. Vor allem erlaubt SVN das einfache Betreiben eines CVS-Exporters, das CVS-Repo kann also bestehen bleiben und seine Downstream-Nutzer (vorerst) weiter zu versorgen. Den großen Sprung wie git oder hg zu machen erscheint natürlich erst einmal verlockend, aber man muss sich auch vor Augen, was es bedeutet. Hunderte Committer müssen komplett umlernen (und einige waren schon über den Sprung auf SVN nicht glücklich, wollten CVS behalten) anstatt sich nur umgewöhnen. Etliche Scripte müsste man neuschreiben. Man müsste Workflows und Arbeitsweisen anpassen. git, hg und co mögen ihre Vorteile haben, aber ein Umstieg ist halt auch recht invasiv. Vielleicht ist man dafür in einigen Jahren bereit, aber im Moment denke ich, dass man mit SVN die beste Wahl getroffen hat.

[unull]

Zitat von Frank

Wo liegen denn die Unterschiede Eurer Meinung nach
zwischen Subversion, Mecurial und Git?

Zumindest git betreffend (von Mercurial habe ich keine Ahnung):

* einfaches Erstellen von Branches (-> nicht-lineare Entwicklung)
* deutlich besseres Mergen
* es ist von vornherein dezentral ausgelegt

[Kamikaze]

Mal so nebenbei warum Branching und Merging so wichtig sind. Denkt mal an den Aufwand eine neue Xorg Version in die Ports einzupflegen.