[PostNAS] Relationen-Spalten, Vereinheitlichen der Entwicklungs-Zweige

[Jürgen E. Fischer]

Moin Frank,

On Fri, 29. Aug 2014 at 18:28:43 +0200, Frank J. wrote:
> mir fehlt ein wenig die Erfahrung mit Community-SVN-Projekten.
> Ich hab das erste mal "gebrancht" und weiß nicht, was das übliche  
> Vorgehen dabei ist.

Ich dachte nur Du hättest gebrancht - hast Du aber gar nicht.  Wenn ich das
richtig sehe, hast du nur eine weiteres Unterverzeichnis mit Kopien der
Original angelegt und commitet.


> Ich bin von der Überlegung ausgegangen, dass der Trunk in den  
> Dokumentationen und Anleitungen als die Stelle benannt ist, an der man  
> eine funktionierende Version herunter laden kann.

> Das wollte ich nicht kaputt machen. Die meisten, die daraus etwas laden,
> wollen nur benutzen  und nicht entwickeln.

Die laufende Entwicklung wird normalerweise in Trunk gemacht.   Ist eine
Version fertig wird gebrancht.  Der Stand in Trunk und dem neuen Branch ist
dann erstmal der gleiche.  Man kann den Branch mit dem stabilen Stand
auschecken, auch wenn es inzwischen in Trunk weitergegangen ist und dem Zweig
auch noch nachträgliche Korrekturen basierend auf dem stabilen Stand commiten.

Für 0.3, 0.4, 0.5 und 0.6 gibt es auch jeweils einen Branch.   Für 0.7 bisher
keinen.  Und nachträglich geht das auch nicht mehr ohne die alten Stände vorher
zu reverten (glaube ich zumindest - meine SVN-Kenntnisse sind etwas
eingerostet, weil ich schon lange zu git gewechselt bin).

Das neue Verzeichnis hat gegenüber dem Branch und dem weiterarbeiten in Trunk
den Nachteil, dass für SVN die ursprüngliche Version und die Kopie im
Unterverzeichnis 0.8 keinen Zusammenhang haben, es die Kopie einfach als
komplett neue Datei auffasst und daher die Änderungen zwischen der
ursprünglichen und der ersten Änderungen auch nicht verfolgt hat (falls es beim
ersten Commit mit Unterverzeichnis schon Änderungen gegenüber dem Original
gab).  

Und wenn die Dateien später wieder zurück über die alten Dateien kopiert
werden, wird SVN zudem auch nur eine große Änderung feststellen - die
Einzeländerungen dann nicht Protokoll hervor.

> Ich wollte aber auch nicht solange warten, bis alle Komponenten komplett  
> umgestellt sind so dass wieder alles zusammen passt.

> Erst wenn kein Programm und kein View mehr "alkis_beziehungen" verwendet  
> kann das aus dem Schema und aus dem Trigger heraus genommen werden.
> Dann muss noch viel getestet werden, weil fast jede Komponente angefasst  
> wurde. Dann erst ist die 0.8 einsatzbereit - "fertig" wird so was ja nie.

> Ich wollte aber die Zwischenergebnisse schon bereit stellen. Auch andere  
> sollen die Chance haben, ihre Ergebnisse beizutragen.

Trunk für die Entwicklung und Branches für die "stabilen" Versionen zu
benutzen, hat auch den Vorteil das man bei Änderungen nur so vorsichtig sein
muß.   Meine Änderungen habe u.a. deswegen nicht committed, weil Trunk wohl
produktiv eingesetzt wird.  Wenn Trunk nur für die Entwicklung eingesetzt wird,
darf es zwischendurch durchaus mal kaputt sein.

Ich habe übrigens gestern in
https://github.com/norBIT/alkisimport/commit/d636a643199a5ec243051700521210176b51ee65
viele Deiner Änderungen übernommen.



Jürgen

-- 
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140829/b6eb58f1/attachment.pgp>