Wie managed ihr das auf dem PC??
Macht ihr die Sicherung übers Netzwerk an ein Repository Server ala Microsoft Team Server oder eher Tortoise`?

Wenn man was ernsthaftes machen will würde ich auf jeden Fall ein SCC System verwenden. Alleine schon, weil mann dann die ganze History hat. Sonst ärgert man sich zu oft, wenn man was ändert, und dann draufkommt, dass die alte Version besser funktioniert hat.

Und Backups mit "eine Kopie pro Tag/Woche" o.ä. sind für mich persönblich Der Horror (tm). Wenn schon mit History, dann gleich ordentlich, so dass man schön alles mit wenigen Klicks diffen/reverten etc. kann.

Und Backups mit "eine Kopie pro Tag/Woche" o.ä. sind für mich persönblich Der Horror (tm). Wenn schon mit History, dann gleich ordentlich, so dass man schön alles mit wenigen Klicks diffen/reverten etc. kann.

Das ersetzt aber nicht die Sicherheitskopien jede Woche oder alle 2 Wochen woanders hin (falls deine "wirklich wichtigen" Sachen nur an der einen externen Stelle liegen). Die solltest du dennoch machen, auf das ganze repository (bei SVN zum Beispiel svn dump blubb > blubb.dump). Ansonsten stehst du mal blöd da, wenn aus irgendeinem Grund die interne Struktur zerstört wird oder das repository verloren geht (kann auch durch nen Hardware-Fehler verursacht werden).

Vorausgesetzt natürlich man verlässt sich auf das SCC System, also darauf, dass sich das nicht selbst das Repository zerschiesst, und es dann bei einem Dump nicht merkt. Das wäre dann natürlich blöd, weil man dann ein kaputtes Backup hätte. Aber irgendwo muss jede Paranoia ein Ende haben

Und: bei SVN kann man das mit inkrementellen Dumps umgehen.
So machen wir das z.B. bei uns in der Firma: jede Nacht wird eine "hotcopy" gezogen (und die alte Kopie dann gelöscht), und zusätzlich dazu ein inkrementeller Dump aktualisiert.

Idealerweise hängt man das Dump aktualisieren gleich in ein post-commit Script.

Naja, man kann es aber auch übertreiben
Vor allem wenns nur Hobby is, und es eigentlich um nixe geht.

Ansonsten habe ich noch ein RAID1 zur Sicherung.

Reicht es nicht, den Code einfach nur nochmal in einen extra Ordner zu packen? Also, wenn ich meine Projekte jetzt in Eigene Dateien\Projekte habe, dass ich sie dann noch mal nach Eigene Dateien\Projekte\Backup kopiere? Sollte doch sicher genug sein.

Nö, das ist ziemlich unsicher. Wenn die Festplatte ausfällt (hohe Wahrscheinlichkeit), dann ist der Quellcode weg. Hinzu kommt, dass du nicht die Annehmlichkeiten und Vorteile eines modernen Versioncontrolsystem hast.

Ratloser schrieb:

Reicht es nicht, den Code einfach nur nochmal in einen extra Ordner zu packen? Also, wenn ich meine Projekte jetzt in Eigene Dateien\Projekte habe, dass ich sie dann noch mal nach Eigene Dateien\Projekte\Backup kopiere? Sollte doch sicher genug sein.

Nö, das ist ziemlich unsicher. Wenn die Festplatte ausfällt (hohe Wahrscheinlichkeit), dann ist der Quellcode weg. Hinzu kommt, dass du nicht die Annehmlichkeiten und Vorteile eines modernen Versioncontrolsystem hast.

100% ACK

Ich benutze immer ein Versionscontrolsystem, nicht nur wegen dem Backup, sondern weil es auch den gewöhnlichen Programmieralltag unterstützt (Fehlersuche, Dokumentation etc.). Ich benutze vor allem git (http://whygitisbetterthanx.com/) und mirror das auf meinem vserver und ggf. anderen Seiten (github, Institut, Firma etc.) und auf meinem Laptop.

mach ich genauso. Hab für ein Projekt mehrere git Repositories auf unterschiedliche Server (Server von der Arbeit, Uni-Server, zu Hause), die ich immer wieder synchronisiere. Das ist was ich von git am meisten mag: man kann sich super schnell ein Repository bauen, ohne iregendwelche Serverkonfiguration verändern zu müssen.

ich nutze Mercurial (ähnlich wie git, inzwischen denke ich zwar unterlegen, aber mir reicht's).

Das Repository wird (zusammen mit anderen persönlichen Daten) zusätzlich nochmal mit rdiff-backup versioniert, falls ein Fehler in Mercurial das Repository zerschießen sollte und dieser Ordner wird über verschiedene Rechner verteilt gespeichert und gepackt und verschlüsselt automatisch wöchentlich auf einer Server hochgeladen.

Viele Grüße
Christian

Sourcecode: Im Repository auf meinem VServer...
Lochkarten: In einem Kästchen in meinem Regal...

Gemeißelte Steintafeln: Als Gipsabdruck im Keller

Machine schrieb:

Sourcecode: Im Repository auf meinem VServer...
Lochkarten: In einem Kästchen in meinem Regal...

Gemeißelte Steintafeln: Als Gipsabdruck im Keller

Wandmalereien: in der ganzen Wohnung.

Zusätzlich hab ich mir 1000 Free-Mail-Accounts eingerichtet, mit Forwarding in einer grossen Schleife, immer von einem zum anderen. Da schick ich die Backups dann im Internet im Kreis. Damit die auch mal was von der Welt sehen.

Ich versioniere mit Subversion. Backups werden von mir auf DVD-RAM gemacht.

Optische Datenträger sind wirklich sehr unsicher, warum nicht einfach eine externe Festplatte kaufen?

Bulli schrieb:

Ich versioniere mit Subversion. Backups werden von mir auf DVD-RAM gemacht.

Optische Datenträger sind wirklich sehr unsicher, warum nicht einfach eine externe Festplatte kaufen?

Externe Festplatten haben (nach meiner Erfahrung) auch die Angewohnheit einen verfrühten Tod zu sterben. Vielleicht hatte ich (und ein bekannter von mir, bei dem ich das auch beobachten konnte) natürlich auch bloss Pech.

Ich würde trotzdem eher ne normale 3,5" SATA Platte nehmen, und die in so ein Sharkoon SATA Quickport Pro Teil reintun. Bzw. halt ins Regal legen wenn sie nicht gebraucht wird.

Das ist der Vorteil von Git, git ist nicht zentral wie svn und cvs.

Was spricht gegen 2 mal Git auf 2 verschiedenen Festplatten?

nichts, solange es auch zwei verschiedene rechner sind.
nur ein rechner hat noch die anfälligkeit mit dem alldiskswipeout-virus.

Git user schrieb:

Was spricht gegen 2 mal Git auf 2 verschiedenen Festplatten?

nichts, solange es auch zwei verschiedene rechner sind.
nur ein rechner hat noch die anfälligkeit mit dem alldiskswipeout-virus.

Dafür gibt's doch externe Festplatten.

Was spricht gegen 2 mal Git auf 2 verschiedenen Festplatten?

Das ist der Vorteil von Git, git ist nicht zentral wie svn und cvs.

http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt

Git user schrieb:

Was spricht gegen 2 mal Git auf 2 verschiedenen Festplatten?

Das ist der Vorteil von Git, git ist nicht zentral wie svn und cvs.

http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt

Naja, bei Git brauchst du keine Hooks einzubinden und kein extra Tool zu benutzen, dass andere Limitierungen hat.

[...]To do this you'll need to set up a pre-revprop-change hook script that
lets the user you'll run svnsync as make arbitrary propchanges.[...]

Q: What if I want to check out from a mirror, but commit to the master?

A: That's possible, but requires some gymnastics.[...]

[...]Note that you should NEVER commit changes to a mirror other than
via svnsync, so to avoid accidentally doing so you may want to add
a start-commit hook script[...]

Optimizer schrieb:

Git user schrieb:

Was spricht gegen 2 mal Git auf 2 verschiedenen Festplatten?

Das ist der Vorteil von Git, git ist nicht zentral wie svn und cvs.

http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt

Naja, bei Git brauchst du keine Hooks einzubinden und kein extra Tool zu benutzen, dass andere Limitierungen hat.

Und ganz ehrlich: Toll, für SVN gibt es ein Tool, mit dem man Read-Only-Kopien von Repos erstellen kann. Bestens, das ist ein echter Vorteil gegenüber einem VCS, bei dem jede Kopie des Repos voll funktionstüchtig ist.