Richtlinien 

1. Entsprechend dieser Best Practices:  http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html    ("Branch when needed"-System)
   
   
2. Ein separates Repository pro (logisch zusammenhängendem) Projekt  
   1. ein "zusammenhängendes Projekt" können z.b. mehrere Visual Studio-Solutions sein, welche die gleiche easyLogic-Datenbank nutzen (Assembly, externe Prozesse, ggfs. Website )
   2. Server- u. clientseitige Projekte in getrennte Repositories
   3. Projekte von großen Kunden, in denen es mehrere Assemblies für eine gemeinsame easyLogic-Datenbank gibt, ggfs. ebenfalls in separate Repositories aufteilen  
      
      
3. Namensschema für Repository:  
   
   1. kunde-projekt-[unterprojekt|plattform]-[client|server|...]
      Zum Beispiel:
      
      • dvv-archiv   
      • trenz-ticketsystem
      • trenz-el-accountverwaltung
      • trenz-el-client
      • maritim-pia-ios-client
   2. Repository-Namen vollständig in kleinbuchstaben
      
   3. Trennzeichen im Repositorynamen: -   (Bindestrich)
      
      
4. Repository-Layout (s. https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-layout):
   
   • trunk  (=>  "Entwicklungsstand", lokal u. auf einer DEV-Datenbank)
   • branches   
     
     • test  (ggfs.)
     • live  (falls es nur jeweils EINEN live-Stand gibt - z.b. bei Website-Projekten mit einer DEV- u. einer LIVE-Umgebung)
     • 3.13  - 3.14 - etc.   (release-branches pro releaster Version, v.a. für Client-Projekte (mobile Apps, easyLogic-Clients, ..)
     • featureXYZ      (Featurebranch, oft für langfristige Entwicklung)
   • tags    (markieren einen Release-Stand, ggfs. zukünftig automatisiert erzeugen)
     
     
5. Checkout und lokale Verzeichnisstruktur:       
   Pro Trunk oder Branch wird eine eigene Working Copy ausgecheckt.
   

   • TRUNK - in ein Verzeichnis mit dem Projektnamen (ohne "trunk")

   • BRANCHES - in ein Verzeichnis mit dem Projektnamen mit angehängtem "_branchname"  (Trennzeichen: Unterstrich)

   Beispiel - folgende Repositorystruktur:

   • • /trenz-ticketsystem
       
       • /trunk
       • /branches/live
       • /branches/3.14

   Wird lokal ausgecheckt in zwei separate Working Copies:

   • • D:\SVN\trenz-ticketsystem\                 (trunk)
     • D:\SVN\trenz-ticketsystem_live\          (branches/live)
     • D:\SVN\trenz-ticketsystem_3.14\        (branches/3.14)        

    

6. Ein Repository kann sich unterhalb von "trunk" bzw. "branches/branchname"  sinnvoll weiter untergliedern, z.B. in:   
   
   • _dev    (*.elaproj,  replace.bat, ...)
   • assembly
   • client
   • doc
   • libs
   • src
   • server
   • web
   • tests
   • tools
   • ...

---

Neue Struktur:

Arbeitsgrundlage / noch unvollständiger Entwurf.

Rot markiert = Verzeichnisse, die m.E. nicht mehr in Benutzung sind und archiviert werden können.