Struktur in svn

Ich habe nachgedacht wie die Struktur der Ordner sein sollte. Und habe entschieden die Struktur von elgg zu übernehmen und schlage vor wir fangen mit core file an.

Was meint ihr dazu?

Dann wollten wir formel und informel übersetzen.

Frage an euch wie vergeben wir am besten die versionsnummern zu sprachdateien? Sollten meiner Meinung nach einfach und verständlich sein.

Es wäre wichtig die Struktur zu besprechen befor wir anfangen.

Warte auf eure Antworten.

 

  • moin moin,

    dem stimme ich zu. Die Struktur sollten wir 1 zu 1 von elgg übernehmen. Genau so eine formell und eine Informelle Version wobei wir mit informell anfangen sollten. Die  Priorität sollte dann auf der neuseten core (svn) und der darin befindlichen Plugins liegen. Meiner Meinung nach sollten wir keine Plugins übersetzten die nicht unter der neusten Version laufen?!

    Weiter, sollten wir eine Auswahl der "most popular mods" erstellen die wir mit Übersetzen wollen. Gibt es files im core die hardcoded sind?

    Meiner Meinung nach sollten wir die Versionsnummern analog zur elgg Versionsnummern vergeben!?

    Werde mir jetzt mal die google code Geschichte anschauen.

    Bis dahin, ich freu mich.

    cheers

    PS: hat einer von euch zufällig die ungefähre Anzahl der zu übersetzenden Wörter?

  • Machen wir informel zuerst.

    Ja denke auch nur die neusten Versionen.

    Most popular. - gute Idee.

    Ja in der Version 1.6.1 z.B. riverdashboard. Da gibt es welche.

    Das mit Versionsnummern ist auch gut.

    Die ungefähre Anzahl der zu übersetzenden Wörter... "viele" ;)

    Mit Google Code svn arbeiten zu können sollte man sich tortoise svn installieren, aktuelle version hier http://tortoisesvn.tigris.org/

     

  • Bischen was zum lesen. Irgendwo geklaut.

     

     

    Begriffe

    Damit wir alle über das gleiche reden und jeder die verwendeten Begriffe im Zusammenhang mit Subversion kennt, sollen die Wichtigsten in den folgenden Abschnitten zumindest grundlegend erläutert werden. Repository und Arbeitskopie sind dabei in Subversion "eingebaute" Begriffe. Trunk, Branches und Tags stehen für die Strukturierung eines Softwareentwicklungsprojektes, um das Arbeiten an verschiedenen Teilprojekten und unterschiedlichen Versionen zu ermöglichen. Diese Strukturierung basiert auf Vorschlägen der Subversion-Entwickler und ist für kleine Projekte wie unsere Firmware bzw. Erweiterung unkompliziert und effizient einsetzbar.

    Repository

    Als Repository oder zu Deutsch Projektarchiv wird das gesamte mit einer Subversion-Instanz versionierte und verwaltete Projekt bezeichnet. Repositories bestehen lediglich aus Dateien und Verzeichnisstrukturen, dabei obliegt es dem Entwicklerteam, ob und inwieweit das ganze strukturiert ist (z.B. nach Trunk, Tags und Branches, siehe die folgenden Begriffe). Vorgaben zur Erstellung der Verzeichnisstruktur gibt es dabei nicht, da SVN Versionierung und Strukturierung im Gegensatz zu anderen (älteren) Versionskontrollsystemen trennt.

    Trunk

    Trunk bezeichnet den aktuellen Entwicklungszweig eines Softwareprojekts. Am Beispiel der Firmwareerweiterung für das Weimarnetz entspräche der Trunk der Firmwareerweiterung vom 25. April für die Firmwareversion 1.2.5.

    Branches

    Als Branches werden Entwicklungszweige bezeichnet, die ausgehend vom Hauptentwicklungszweig (Trunk) parallel weiterentwickelt werden, um beispielsweise an kommende Firmwareversionen angepaßt zu werden, die jedoch noch nicht im produktiven Einsatz ist. Somit ist es möglich, daß mehrere Versionen gleichzeitig gepflegt werden können.

    Tags

    Tags sind Entwicklungszweige, in die keine Entwicklungsarbeit mehr fließt. Das heißt, hierher werden die Entwicklungszweige verschoben, welche mit hoher Wahrscheinlichkeit nicht mehr verändert werden. Dann können unter anderem Firmwareerweiterungen sein, deren grundlegende Firmware nicht mehr eingesetzt wird.

    Vom Trunk zu Branches oder Tags

    Wie komme ich vom Hauptentwicklungszweig zum Branch oder Tag? Ganz einfach, die aktuelle Arbeitskopie wird mit einer Subversion-eigenen Funktion kopiert. Um auf einem parallelem Entwicklungszweig weiterzuarbeiten muß dann noch die Arbeitskopie auf den neuen Pfad umgestellt werden (dafür gibts auch eine Subversion-eigene Funktion)

    Um später Parallelzweige wieder zusammenzuführen, z. B. parallele Entwicklungen in den Hauptentwicklungszweig einfließen zu lassen, "mischt" man beide Kopien mit einer Subversion-eigenen Funktion. Konflikte und Überschneidungen können mit Hilfe von Differenzprogrammen aufgelöst werden.

    Arbeitskopie

    Als Arbeitskopie wird der aktuelle Entwicklungszweig bezeichnet, auf dem man gerade entwickelt bzw. ändert. Das können Trunk, Branches oder sogar Tags sein.

    Operationen/Aktionen

    Checkout

    Ein Checkout bezeichnet die erstmalige Übertragung einer Arbeitskopie in ein lokales Entwicklungsverzeichnis. Es ist möglich, die aktuelle, aber auch eine ganz bestimmte Version der Arbeitskopie auszuchecken. Beim Checkout werden im Zielverzeichnis vorhandene Dateien ohne Rücksicht auf Verluste überschrieben, doch einerseits sollte ein Checkout in ein leeres Verzeichnis erfolgen und andererseits sollten Änderungen mit Update und Commit gepflegt werden.

    Checkouts sind weiterhin sinnvoll, wenn ein komplett neuer Entwicklungszweig erstellt wird oder man einen bestimmten Entwicklungsstand aufnehmen will (z.B. wenn man sich die eigene Arbeitskopie verkonfiguriert hat).

  • Ich möchte 2 Hauptzweige erstelen

    Beta und Finale. Die bedeuten: Beta - unfertige übersetzungen.

    Finale - hier ist alles clean. Alles ist übersetzt und hartcodierte strings in dem entsprechenden plugin existieren nicht mehr.

    Bei Finale müssen wir alle "hardcoded strings" eliminieren, ist eigentlich keine Übersetzungsarbeit, muss ich aber machen um saubere Übersetzung zu bekommen.

    Dafür ist es auch wichtig eine testseite zu machen. Ich frage Brett ob er uns so eine SEite zur verfügung stellen kann.

  • Das mit den zwei Zweigen und der Testseite hört sich vernünftig an.  

German Support Group

German Support Group

The German support group within the Elgg community.