Re: [Fwd: Re: sparse checkouts vs. branches]

Hallo Neels,

gab es hier noch weiteren Kontakt? ... möglicherweise gehen wir in anderem
Zusammenhang jetzt nochmal auf Herrn Rother/ Stuhlemmer zu,

beste Grüße

Olaf

Neels J Hofmeyr schrieb:
> Ich frag mal ob er uns sein skript schickt.
> So aus interesse.
>
>
> ------------------------------------------------------------------------
>
> Betreff:
> Re: sparse checkouts vs. branches
> Von:
> Kai Stuhlemmer <k.stuhlemmer_at_technisat.de>
> Datum:
> Fri, 06 Mar 2009 08:02:21 +0100
> An:
> Neels J Hofmeyr <neels_at_elego.de>
>
> An:
> Neels J Hofmeyr <neels_at_elego.de>
> CC:
> n.rother_at_technisat.de
>
>
> 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
>>
>>
>
>

-- 
Olaf Kosel
Director Project Management
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Building 12
13355 Berlin, Germany
fon: +49 30 2345 8696      mobile: +49 173 88 173 61
fax: +49 30 2345 8695      http://www.elegosoft.com
CEO Olaf Wagner; Office Berlin;
District Court Berlin-Charlottenburg HRB 77719
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1561703