CVS zum Datenabgleich zwischen unterschiedlichen Kisten?

[Stefan U. Hegner]

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 at hegner-online.de, my Cyberhome http://www.hegner-web.de|
\ GPG-Fprint D9DB 51BD 2DA6 9B3A 41CB  0287 05A1 8D11 38BA CE91 /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lug-owl.de/pipermail/linux/attachments/20040525/0ad96c37/attachment.sig>