[linux-l] Verteilte Versionskontrollen zuerst lernen?

[Volker Grabsch]

Thomas Schmidt <schmidt at netaction.de> schrieb:
> Es gibt sicherlich ein paar Gründe, dass SourceForge an Subversion
> festhält.

Ähhm ... ich glaube, du hast mich missverstanden.

Es ging mir _nicht_ darum, welche VCS heute von SourceForge
unterstützt werden.

Es ging mir darum, dass SourceForge ewig gebraucht hat, um neben
CVS auch Subversion anzubieten. Daher war damals nicht zu erwarten,
dass SourceForge zeitnah ein DVCS unterstützen würde. Das könnte
ein Hemm-Faktor für Programmierer gewesen sein, ein DVCS zu imple-
mentieren (ohne Hosting würde es kaum jemandem nutzen).

Aber dieses Argument hatte sich schon damals erledigt, weil es
schon damals andere Hoster wie Savannah gab, die Subversion zeitnah
unterstützt hatten. Man konnte also davon ausgehen, dass zumindest
diese Hoster auch ein DVCS schnell unterstützen würden. Was ja dann
auch passiert ist. (Savannah bietet Marcurial, Git, Arch, etc. an)

Zudem waren die DVCS leichter zu hosten, wie bereits erklärt. BTW,
einige Leute hosten ihr Repository einfach direkt im Webspace von
SourceForge (Lesend per HTTP, schreibend per SSH/SFTP). :-)

Das heißt, man konnte auch damals schon davon ausgehen, dass ein
DVCS nicht mangels Hosting-Möglichkeiten im Sande verlaufen würde,
und sich die Mühe, eines zu implementieren, lohnen würde.

> -Die Logik Repository -> Copys ist intuitiv verständlich, bei mehreren
> gleichberechtigten Repositories muss man sich reindenken und könnte aus
> Versehen auf dem Server etwas ausführen, das eigentlich auf dem
> Arbeitsplatz gemacht werden sollte. Subversion hat nur eine simple
> Zählung von Versionsnummern, da kann man nicht durcheinanderkommen. Die
> Working Copys führen keine unterschiedlichen Stände und haben für sich
> genommen nicht viel mit Versionsverwaltung zu tun. Alles
> Vereinfachungen.

Mercurials "hg push" achtet per Voreinstellung darauf, dass es
auf dem Server keine "öffenen Äste" (multiple heads) gibt. Das
heißt, auch bei den DVCS ist man daran interessiert, dass Konflikte
_vor_ dem Hochladen aufgelöst werden. Somit ist auf Serverseite
ebenfalls alles stets schön säuberlich "aufgefädelt". Und fortlaufende
Nummern gibt es entsprechend auch für jede neue Version, zumindest
lokal in jedem Repository.

Will sagen, diese Vereinfachungen gibt es bei den DVCS ebenfalls.
Aber sie kommen nicht in Form von Beschränkungen, sondern in Form
von sinnvollen Defaults bzw. sinnvollen Abkürzungen.

> -Bei DVCS ist jede Kopie ein vollwertiger Ersatz. Vielleicht befürchtet
> SourceForge, dass die Projekte zu schnell wegziehen?

Man konnte sich schon immer von SourceForge den aktuellen CVS-Tarball
herunterladen, der enthielt das gesamte serverseitige CVS-Repository.
Für Subversion müssten die das inzwischen auch anbieten.

Das heißt, umziehen kannst du sowieso jederzeit.

Und das ist auch aus Sicht von SourceForge ganz sinnvoll, weil es
deren Admins von nervigen Anfragen à la "Könnt ihr mir bitte mein
Repository fürs private Backup zusenden?" befreit.

> Möglicherweise halte ich auch nur an der Subversion-Denkweise fest und
> habe die DVCS-Denkweise nicht verstanden.

Joel Spolsky zufolge könnte genau das der Fall sein. ;-)

http://www.joelonsoftware.com/items/2010/03/17.html



Gruß,

    Volker


> 
> 
> Thomas
> 
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> Die Mailingliste der BeLUG (Berliner Linux User Group)
> 
> Wenn du diese Mailingliste  abbestellen willst, gehe bitte auf
> https://mlists.in-berlin.de/mailman/listinfo/linux-l-mlists.in-berlin.de
> und trage dich dort bitte aus

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR