Moin Liste, ich möchte gerne meine Daten auf unterschiedlichen Kisten (Büro, Notebook, zu Hause) automatisch abgleichen. Vor Zeiten habe ich das unter Windumm mit der Funktion "Syncronisieren" des Windows-Commanders ganz zufriedenstellend bewerkstelligt. Nun scheint mir CVS u.U. ein geeignetes Tool. (Wenn jemand noch was geeigneteres weiß, bin ich ganz Ohr!) - Aber da ich bisher keinerlei Erfahrungen damit habe, wollte ich im Vorfeld mal meine Pläne schildern, um mit Eurer Hilfe vielleicht die eine oder andere Falle zu umgehen. ... Frage 1: Macht CVS bei überwiegend binären Daten wirklich Sinn? Wenn ich mir meine Daten ansehe, so sind das z.B. PDFs, OOo-Daten (.s[x|t]?), Grafiken (PNG, XCF, Gif, Jpg...), Archive (Zip, tgz, tbz2), HTML Dateien, ja und irgendwo auch eine Handvoll ASCII Dateien. Wenn CVS jetzt jede Änderung mitschreibt, ist das dann bei Binärdaten per Definition die ganze Datei? Selbst wenn nicht schreit das nach enorm viel Plattenverbrauch. - Gut, ich habe eine Versionshistory, die manchmal nett sein kann, aber eigentlich ist das mehr ein nettes Feature als ein must-have. Eine Möglichkeit hier die Versionen zu begrenzen wäre ja entgegen dem Grundgedanken von CVS und ist daher sicher nicht gegeben, oder? Frage 2: ein oder mehrere Projekte? Dafür, dass ich die Daten nach bestehenden Verzeichnissen in mehrere Projekte aufteile spricht, dass dann die jew. Updates schneller gehen und ich u.U. auch nur einen Teil meiner Daten in den Sandkasten auschecke ... Dagegen spricht der Fehlerfaktor Mensch. - Da springt man mal schnell in ein anderes Verzeichnis und hat prompt weder ein update noch eine commit gemacht. Oder seht Ihr da noch andere Aspekte? Frage 3: Dateien automatisch auf Binär flaggen? Im CVS-ebook auf LIDN habe ich unter http://lidn.sourceforge.net/books/cvs-1.11.1p1/book/Wrappers.html gelesen, das ich mit Hilfe einer "cvswrappers" Datei die Daten im Repository auf Basis des Dateinamens als "binär" flaggen kann. So wie ich das verstehe, würde ich da dann einfach reinschreiben: *.pdf -k 'b' *.PDF -k 'b' *.sx? -k 'b' *.SX? -k 'b' *.st? -k 'b' *.ST? -k 'b' ... usw. Hat jemand von Euch da schon ein mehr oder minder "umfassendes" Werk für die cvswrappers, oder ist es aus Gründen der Fehlervermeidung bei Verzeichnissen mit überweigend binären Anwendungsdaten angebracht, für das Projekt "* -k 'b'" zu definieren? Grundsätzlich wäre wohl das beste, wenn ich die cvswrappers in CVSROOT ablege. Nur im Falle einer "* -k 'b'"-Variante wäre die .cvswrappers für die jew. Projekte sinnvoller, damit ich in der Repository bei Bedarf auch Sourcen und anderen Krams lassen kann, oder? Frage 4: ... oder doch mit rsync? Wenn ich mir diesen ganzen Krams ansehe, muß ich mich fragen, ob es nicht vielleicht doch sinnvoller ist, auf den Clients den aktuellen Baum mittels rsync abzugleichen und geänderte Dateien in ein tmp Verzeichnis zu schreiben und manuell mit dem Server abzugleichen. ... Oder hat da noch wer eine kreative Idee, das benutzerfreundlicher zu machen? Bin sehr auf euren Input gespannt! Gruß Stefan. -- / Stefan Ulrich Hegner aka "Hegi" - Loehne/ Westfalen - Germany \ | stefan@hegner-online.de, my Cyberhome http://www.hegner-web.de| \ GPG-Fprint D9DB 51BD 2DA6 9B3A 41CB 0287 05A1 8D11 38BA CE91 /