[Fwd: Re: sparse checkouts vs. branches]

Ich frag mal ob er uns sein skript schickt.
So aus interesse.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1280523

attached mail follows:

Hallo Neels,

vielen Dank für Deine Email. Deine Zusammenfassung ist im Wesentlichen korrekt, ich habe aber noch
einige Anmerkungen zu unserem "Problem". Als Ausgangspunkt möchte ich noch einmal erwähnen, dass wir
erst vor Kurzem unser Repository von CVS zu Subversion migriert haben. Unsere Erfahrungen sind somit
stark von CVS geprägt. CVS kennt das Konzept der Module, welches in dieser Form nur sehr schwer und
erst seit Version 1.5 mit Subversion dank "sparse checkout" nachzubilden ist. In diesem konkreten
Punkt ist Subversion also das schlechtere CVS. In CVS konnte man Modul-Beschreibungen sogar
Datei-genau machen, während sich "sparse checkout" nur auf die Verzeichnisebene beschränkt.

Wie haben wir nun diese Funktionalität nachgebildet? Mein erster primitiver Ansatz war ein einfaches
Shell-Script, welches die Module-Beschreibungen hart kodiert enthielt und bei jedem Benutzer lokal
installiert war. Diese Lösung ist ziemlich wackelig, da sie außerhalb des Repositories existiert und
man sicherstellen muss, dass alle Nutzer mit einem aktuellen Script arbeiten. Deshalb sieht unsere
jetzige Lösung auch anders aus. Ich habe mir eine sehr einfache Modulbeschreibungssprache ausgedacht
und ein Programm "svnmod" dafür geschrieben. Svnmod holt standardmäßig die Modulbeschreibungsdatei
aus dem trunk-Verzeichnis im Repository. Die URL bekommt das Programm entweder über eine
Umgebungsvariable oder per Kommandozeilen-Option. Mit einer anderen Option kann man statt des trunk
einen branch spezifizieren, von welchem die Datei geholt wird (und später auch das checkout
stattfindet). Der Parser liest nun alle Modulbeschreibungen ein (denn eine Modulbeschreibung darf
auch Referenzen auf andere Module beinhalten). Dann werden alle Verzeichnisse, die zu dem
gewünschten Modul gehören, mittels "sparse checkout" geholt. Svnmod benutzt für alle svn-Operationen
den Kommandozeilen-Client svn. Das Tool holt die einzelnen Verzeichnisse übrigens nicht mit
separaten checkouts. Nur das "root"-Verzeichnis wird per "svn checkout --depth files" geholt.
Dann werden die einzelnen Verzeichnisse mittels "svn update --depth files" hinzu gebracht. Damit
erzeuge ich also eine working-copy, die bei Updates und Commits auch als Ganzes behandelt wird.

Die Vorteile dieser Lösung sind:

+ Die Modulbeschreibung liegt im Repository.
+ Sie wird beim Kopieren (branch, tag) automatisch mit kopiert so dass sie
  auch zu den Kopien passt (Das ist übrigens besser als im CVS :-)).

Die Nachteile sind:

- Ich brauche ein zusätzliches Programm für das initiale Checkout. Das ist schlecht
  für GUI-Fans (Tortoise, SmartSVN, Subclipse etc.), welche es auch unter
  Programmierern viele gibt. Für bestimmte Aufgabe bevorzuge ich die auch.
- Die Lösung setzt eine bestimmte Repository-Struktur voraus (trunk, branches, tags).
- Die Lösung ist aufgestülpt.

Eine Unterstützung von Subversion selbst wäre also trotz allem besser. Ich stelle mir das eigentlich
auch gar nicht so schwer vor. Man könnte einfach eine Property "svn:module" einführen, welche als
Wert den Modulnamen enthält. Diese könnte man dann an die gewünschten Verzeichnisse hängen. Wenn man
dann beim checkout noch eine Option hat, mit der man den Modulnamen spezifiziert, dann sollte es für
den Server relativ leicht sein, nur die Verzeichnisse zu liefern, die die entspr. Modul-Eigenschaft
besitzen.

Nun zum Erstellen der Branches. Zuerst einmal muss man sagen, dass Branches ja für
verschiedene Zwecke benutzt werden.

1. Temporäre Branches zur Entwicklung neuer Funktionalität.

2. Release-Branches für die finale Produkt-Entwicklung und Pflege.

Der Fall 1 stellt kein Problem dar. Der Branch ist einfach eine Kopie des Trunk. Die
Release-Branches werden allerdings für ein ganz konkretes Produkt oder eine Produktgruppe erstellt.
Für diese ist i.d.R. nur eine Teilmenge der Quellen wirklich relevant. Wir erstellen sie im Moment
so, indem der Trunk kopiert wird und dann in der Kopie alle irrelevanten Verzeichnisse gelöscht
werden. Das ist mühselig und fehleranfällig, wenn man es händisch tut. Hätte man die oben erwähnte
Property "svn:module", dann könnte man ähnlich wie für das Checkout vorgeschlagen dem Copy-Befehl
einfach eine Option spendieren, mit der man nur Verzeichnisse eines bestimmten Moduls kopiert.

Du vermutest ja, dass wir evtl. ein Strukturproblem haben. Das will ich nicht ganz ausschließen.
Allerdings stellt die Arbeit mit Teilmengen für uns nur eine Optimierung dar. Wir könnten darauf im
Prinzip verzichten, d.h. das Release-Management ist nicht darauf angewiesen. Die Verwendung von
Teilmengen hat allerdings zwei Vorteile:

1. Das Checkout/Update geht schneller, weil nur für das bearbeitete Projekt relevante Verzeichnisse
geholt werden. Alles für dieses Projekt Irrelevante bleibt außen vor.

2. Viele IDEs ermöglichen es, beim Erstellen eines (IDE-)Projektes einen kompletten Quell-Baum ins
Projekt zu holen. Hat man schon nur die relevanten Sachen in der Working Copy, dann kann man einfach
und schnell ein neues IDE-Projekt erstellen ohne irrelevanten Ballast.

So, das war noch einmal sehr ausführlich meine Sicht der Dinge. Wenn Du Interesse hast, dann könnte
ich Dir auch die Quellen von Svnmod zukommen lasse.

Viele Grüße,

Kai

Neels J Hofmeyr schrieb:
> Hallo,
>
> wir haben uns ja auf der Subversion 1.6 Preview über eure Repository/Working
> Copy Struktur unterhalten. Ich fasse mal zusammen was ich mir gemerkt habe:
>
> Ihr habt also einen grossen Baum mit Treibern, Hauptprogrammen u.s.w., aus
> dem Working Copies nach Bedarf "wild" zusammengestellt werden, wobei oft
> tiefere Ebenen eines Verzeichnisses *nicht* mit eingefügt werden sollen.
>
> Gegenwärtig erreicht ihr das mittels einer Serie von sparse checkouts, durch
> ein externes Skript.
>
>
> Ein Problem besteht darin, dass ihr diese zusammengestellten Working Copies
> branchen wollt. Wie sieht das derzeit aus? Etwa eine WC->URL Kopie:
> svn copy ./local/dir http://server/url ?
>
> Das problem ist, dass diese Kopie nunmehr nicht "cheap" ist.
>
>
> Euer Workaround besteht darin, eine URL->URL Kopie zu machen (den gesamten
> Verzeichnisbaum branchen) und eine neue Working Copy aus diesem branch
> zusammenzustellen.
>
>
> Wir hatten kontempliert, dass dieser Vorgang eventuell automatisch sein soll.
>
> Ich sehe inzwischen dass das nicht geht. Die Schwierigkeit liegt einerseits
> darin, dass in diesem Fall die Zusammenstellung der Working Copy dem svn
> client nicht bekannt ist, und andererseits ist eine WC->URL Kopie ein
> beabsichtigtes Feature, bei dem der genaue Zustand der Working Copy im
> Repositorium festgehalten wird. Das wird zum Beispiel beim Erstellen des
> offiziellen Subversion release source tarballs genutzt.
>
>
> Weiter hatten wir in Erwägung gezogen, svn:externals zu benutzen.
>
> Dabei gibt es drei Problempunkte:
>
> 1. Externals haben derzeit nicht die Möglichkeit einer begrenzten Tiefe.
> -> Bei Interesse gäbe es wohl die Möglichkeit, das zu implementieren.
>
> 2. External dirs werden nicht automatisch mit ihrem Elternverzeichnis committed.
> -> Bei sparse checkouts ist das allerdings auch nicht der Fall. Ist es
> tatsächlich ein Problem bei euch? Ich sehe es eher als eine wünschenswerte
> Vermeidung von Teufels Küche.
>
> 3. Externals sind nicht zum branchen in dem Sinne geeignet -- ein kopiertes
> svn:external property erzeugt *keine* Kopie der im External angegebenen URL.
> Das heißt, sobald man sich in das External hineinbegibt, ändert man wieder
> die ursprünglichen Dateien, egal wie oft man das svn:external property
> gebrancht hat. Auch hier würde man also einen branch der ursprünglichen URL
> machen, und das svn:external property daran anpassen, bzw. das Verzeichnis,
> das das svn:external hält, ebenfalls branchen und dann anpassen.
>
>
> Es gibt also offenbar im Moment keine bessere Lösung für eure Situation,
> wegen der Anforderung der begrenzten Tiefe. Ich sehe bei euch (wie ich es
> verstanden habe) aber auch ganz große Gefahren.
>
> Erstens, die Information über die Zusammenstellungen eurer
> Software-Publikationen ist extern, ist nicht im Repositorium enthalten
> (richtig?). Da gibt es also eine Spaltung der Information in zwei parallele
> Systeme, und die Zusammensetzungsinformation ist nicht versioniert
> (Änderungen daran werden nicht in ihrem Verlauf festgehalten).
>
> Zweitens, angenommen eure sparse checkouts sind nicht mit expliziten
> Versionsnummern fixiert: dann habt ihr keine Daten darüber, welche
> Komponente mit welcher an welchem bestimmten Datum funktioniert hat. Sobald
> eine Komponente weiterentwickelt wird, ändert sich der Inhalt aller darauf
> basierenden Produkte, und der vorige Zustand geht verloren...
>
>
> Ich bin mir eigentlich sicher, dass ihr schon Methoden nutzt, um die
> einzelnen Releases festzuhalten. Aber ich habe den schweren Verdacht, dass
> euer Modell mal genau analysiert werden sollte, mit dem Ziel eine einfachere
> und damit bessere Lösung zu finden. Allein eine Umstrukturierung mit klarer
> Abgrenzung einzelner Komponenten in Leaf-Verzeichnisse (worin keine
> Unterbäume vorhanden sind) könnte vieles ermöglichen.
>
> Als gutes Ziel erscheint mir, Externals mit fest fixierten Revisionsnummern
> zu nutzen und somit die Struktur der Produkte zu jedem gegebenen Zeitpunkt
> im Repositorium festzuhalten.
> Weiterentwicklungen und branches sollten immer in der jeweiligen
> Subkomponente erstellt werden, wonach man die Revisionsnummer im
> svn:externals Property anpassen müsste um ein Produkt auf den neuesten Stand
> zu bringen. Somit sind dann die einzelnen Produkte vor Querschlägern aus
> anderen Produkten geschützt: Die svn:externals properties sind ja ebenfalls
> versioniert und jede jemals vorhanden gewesene Konfiguration kann
> wiederhergestellt werden.
>
>
> Das sind so meine Theorien aus der Ferne. Ihr solltet euch Gedanken machen,
> ob eine Umstrukturierung sinnvoll ist. Ich als Subversion Committer werde
> gern kleine bis mittlere Fragen beantworten.
>
> Und falls ihr Beratung für einen Strategiewandel in der Benutzung von
> Subversion braucht, wisst ihr ja, wer die Profis sind: elego Software
> Solutions! ;)
>
> Grüße,
> ~Neels
>
> --
> Neels Hofmeyr
> Software Developer
>
> elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Building 12
> 13355 Berlin, Germany
>
> fon: +49 30 2345 8696
> fax: +49 30 2345 8695 http://www.elego.de
>
> CEO Olaf Wagner; Office Berlin;
> District Court Berlin-Charlottenburg HRB 77719
>

-- 
*********************************************************************
 Kai Stuhlemmer
 Dipl.-Inform.
 DVB Group
 Phone: +49 (0)351 45355 6232
 FAX:   +49 (0)351 45355 40
 email: k.stuhlemmer_at_technisat.de
 TechniSat Digital GmbH
 Gewerbepark Merbitz 5
 D-01156 Dresden
 Germany
 Kreisgericht Dresden - HRB 657
 Geschäftsführer: Peter Lepper, Friedhelm Flamm,
                  Jürgen Beuthner, Hans-Joachim Baer
 USt.IdNr. DE 140 212 281
 Steuer-Nr. 27/43/666/0133/5
*********************************************************************