[Fli4l_dev] svn / Stable Branch

Alexander Dahl lespocky at web.de
Mo Mär 17 07:42:18 CET 2014


Moin,

Christoph Schulz <fli4l at kristov.de> schrieb:
>> D.h. es werden nicht mehr nur die Binaries für x86 ins svn gepackt
>> sondern zukünftig auch noch die für amd64, arm, mips, ?? o.O
>
> Irgendwo müssen die Binäranteile ja stecken, und bislang hat sich der SVN-
> Repo-Ansatz als sehr bequem herausgestellt. Letztlich ist ein "Repository" 
> ein "Ablageort" für was auch immer, in unserem Fall für Quellen + 
> Binärprogramme. Dass man alles auch anders gestalten kann (siehe unser 
> Tarball-System, siehe unseren Jenkins, der immer mehr Aufgaben erledigt), 
> steht außer Frage. Niemand, der SVN nutzt, ist jedoch gezwungen, das 
> _komplette_ Repository auszuchecken, da SVN seit jeher Sparse Checkouts 
> unterstützt (bzw. verbessert ab 1.5 (2008)), was andere 
> Versionskontrollsysteme entweder gar nicht können oder wie git erst später 
> (1.7.0, 2010) nachgeliefert haben: Man kann einfach src/ und bin/<Arch>/ 
> auschecken, wenn man nur an <Arch> interessiert ist, und den Rest links 
> liegen lassen.

Unter den Voraussetzungen ist das richtig. Wollte man später mal auf ein
anderes Versionsverwaltungssystem migrieren, könnte das interessant
werden, aber das steht ja derzeit gar nicht zur Debatte.

Ich gebe zu, dass auch der Ansatz einen genau definierten Stand einer
Build-Umgebung inkl. Toolchain reproduzierbar zu erzeugen, nicht
unproblematisch ist. Du willst dann ein Archiv aller jemals gebrauchten
Source-Tarballs vorhalten, es ist nicht klar ob die Toolchains später
mit neuen Compilern noch gebaut werden können, also bewahrst Du die auch
auf und dann können immer noch Fehler beim Einchecken der Build-Config
etc. passieren. Um Tarballs zu bekommen, müssten die entweder schon mal
irgendwo abgelegt sein, wo man sie immer wieder bekommt, oder man
kompiliert halt ständig neu.

Der Vorteil läge halt "nur" darin kein 20 GB Repository rumliegen zu
haben und ggf. übertragen zu müssen und so den tatsächlichen Beitrag der
Entwickler auch besser abschätzen zu können. Letztlich macht man's bei
Quellcode ja auch nicht anders und checkt bspw. nur seinen C-Code ein,
aber nicht das kompilierte Programm, weil man das ja immer wieder neu
erzeugen kann.

Kurz und gut: ich will Euch da nicht reinreden, ich war nur überrascht.
O:-)

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0


Mehr Informationen über die Mailingliste Fli4l_dev