Backup/Restore von VisualSVN Server

[Sir Rufo]

Innerhalb eines Projekts keine weiteren Unter-Trunks/Branches etc.
Das Projekt gehört ja zusammen und bildet eine Einheit. Ob es da nun noch integrierte Neben-Projekte zum Testen gibt ist egal.

Anders wäre es, wenn du z.B. eine Form hast und die benötigst du in mehreren Projekten.
Dann legst du für diese Form ein eigenes Repo an und entwickelst das dort.

In die anderen Projekte kannst du dir dieses nun per svn:external hinzufügen

In einigen Projekten benutze ich z.B. die Units von Synapse (Alternative zu den Indys)
Meine Struktur sieht dabei so aus

Code:

trunk
  bin
  ext
    synapse <- via svn:external
  src

Bei svn:external kann man auch die Revision angeben, die man haben möchte.
Ich programmiere also mit der aktuell verfügbaren Revision von synapse.
In ein paar Monaten kann es aber sein, dass die Jungs dort etwas verändert haben, was mit meiner Anwendung inkompatibel ist. Also trage ich bei svn:external auch noch die von mir getestete Revision mit ein.
Hole ich mir dann irgendwann das Projekt wieder aus meinem SVN wird auch automatisch die entsprechende Revision von synapse geholt (damit muss das laufen)
Testweise entferne ich die Revisionsnummer für synapse und aktualisiere. Mit der neuesten Version kann ich nun meine Anwendung erzeugen. Wenn es nicht funktioniert, dann trage ich die alte Revision wieder ein, aktualisieren und alles wieder gut.

Sobald man Zeit hat, passt man entweder die Anwendung an, oder schickt einen Bug-Report.
Die Anwendung wird aber nicht versemmelt, somit bleibe ich entspannt.

[mjustin]

Zitat von Chemiker:

Zitat von mjustin:

Nein, svnadmin arbeitet bewusst nur mit lokalen Repositories. Mit ssh (oder ähnlichen) Remoteclients geht es natürlich auf Umwegen schon.

Das SVN läuft auf einen WHS (abgespeckter MSServer 2003). Das SVN läuft in einem Bereich der nicht gespiegelt wird, deswegen suche ich eine Möglichkeit das Backup in einem bestimmten Zeitabstand zu erstellen.

In diesem Fall würde ich einen "Geplanten Vorgang" hinterlegen der svnadmin z.B. nächtlich ausführt und eine Sicherung erstellt.

Meine Repo-Struktur ist übrigens

Code:

branches
  Projekt1
    feature1
    feature2
  Projekt2
  ...
tags
  Projekt1
    1.0
    1.1
  ...
trunk
  Projekt1
  Projekt2
  Projekt3

...

Third party libraries wie Synapse halte ich ausserhalb des Repositories (ausser bei angepassten Versionen), dort liegen sie dann in eindeutig benannten Verzeichnissen wie x:\Delphi\indy-10.5.8 oder synapse-39.

[Sir Rufo]

Da SVN (und auch andere) einem nicht wirklich vorschreiben wie man seine Verzeichnisse organisiert (auch branches, tags, trunk sind nicht zwingend notwendig) ist es Geschmackssache und kann nach den eigenen Bedürfnissen angepasst werden.

Die Third-Party-Libs in einem definierten Verzeichnis zu halten ist eben auch eine Möglichkeit und ist immer abhängig von dem, was man erreichen möchte oder will/muss.

Meine Entwicklungen laufen auf unterschiedlichen Entwicklungsrechnern (unterschiedliche Delphi-Versionen) und es hat sich dabei (bei mir) als Vorteil herausgestellt, die Third-Patry-Libs als External einzubinden.
Vor allem die, die eh auf einem SVN verfügbar sind. Dadurch habe ich die Möglichkeit die ausgelieferte Version immer korrekt nachstellen zu können.

Zudem muss ich nicht jede Delphi-Umgebung mit den entsprechenden Libs versorgen und auch noch aktuell halten (obwohl man das auch per SVN machen kann )

Es gibt keine allgemeingültige Vorgehensweise wie man die Organisation mit einem SVN realisiert. Es ist und bleibt Philosophie und hängt viel von der eigenen Arbeitsweise und Organisation ab.

Möglich, dass du auch nach einiger Zeit feststellst, dass das alles Bullshit ist und du es komplett anders organisierst. So ist das im Leben. Meine Vorhänge habe ich vor kurzem auch komplett getauscht. Vorher kam ein neues Sofa und umgeräumt habe ich auch. Trotzdem war es vorher nicht falsch und muss jetzt nicht für alle Ewigkeit richtig sein.