Dateien zwischen zwei Systemen teilen



  • Hey,

    ich habe bisher immer nur auf einem System entwickelt und alles war kein Problem. Jetzt ist es aber so, dass ich zum Testen und Kompilieren auch auf ein anderes OS zurückgreifen muss.

    Dabei möchte ich ungern jedes Mal die Dateien umkopieren, weil dabei schnell Fehler passieren können. Außerdem sind die Projekte relativ groß (2 GB) und bestehen aus vielen kleinen Dateien, was den Kopiervorgang ebenfalls erheblich bremst.

    Gerne würde ich weiterhin das eine System zum Entwickeln nehmen und nur zum Bauen das andere, aber das Problem mit dem Kopieren, usw. bleibt natürlich bestehen.

    Meint ihr es macht Sinn hierfür z.B. eine externe Festplatte zu nutzen? Es handelt sich um einen Mac und um ein Windows 7. Ebenfalls wichtig ist auch die Datensicherheit.

    Leider lässt sich die Projektgröße nicht gut reduzieren. Und zippen bringt kaum Zeitvorteil, weil dieser durch den Komprimierungsvorgang an sich zunichte gemacht wird.

    Ideen? Erfahrungen? Tipps? 🙂



  • Beide Systeme stehen übrigens auch lokal in Verbindung und gewissermaßen im gleichen Raum. Meint ihr es macht Sinn irgendwas über das Netzwerk zu machen? Ich hab mit Mac leider keine Erfahrung und weiß nicht, ob ich hier Dateien für Windows freigeben kann.


  • Mod

    Irgendwie musst du schon eine physische Verbindung herstellen, sei es über eine geteilte Platte, ein Kabel, oder einen Funkkanal. Das Kabel oder Funk ist dabei die wohl mit Abstand angenehmste Alternative, zumindest wenn beide Rechner gleichzeitig eingeschaltet sind. Was willst du mehr wissen?



  • Wenn der Grossteil der 2GB statisch sind, dann sollte ein Version Control System ziemlich gut funktionieren (SVN, GIT, ...).

    Wenn sich der Grossteil der 2 GB ständig ändert, dann natürlich nicht.
    In dem Fall würde sich vielleicht eher etwas wie ein Harddisk File (VHD, ...) anbieten. Dabei entfällt die Zeit die zum Komprimieren/Dekomprimieren nötig wäre, und du hättest trotzdem ein grosses File das sehr schnell über ein geeignetes Netzwerk (Gigabit) transporitert werden kann.



  • Na ja, ich will halt nur wissen was sich eher eignet.

    Das mit dem Harddisk File klingt eigentlich sehr interessant, aber eigentlich mag ich vom Duplizieren jeglicher Art weg kommen, denn ich bin manchmal etwas schusselig und komme da früher oder später sicher durcheinander welches File denn nun das richtige ist...

    Ich denke, ich werde mal die Netzwerklösung versuchen. So kann ich den Mac als Storage nutzen, denn der hat eh eine SSD. Die gebe ich dann frei und Windows greift darauf zu (sofern das möglich ist). Wenn ich dann alles fertig habe, dann kann der Mac wiederum die Dateien nehmen und sein eigenes Binary erzeugen.

    Vorallem werden von diesen Daten eh nicht immer alle direkt benötigt sondern immer nur just in time. Das heißt, das darauf zugreifende Programm benötigt vielleicht immer nur einen Bruchteil, was die Latenz ja ebenfalls wieder verringert. Wenn ichs kopiere, dann muss aber einfach alles da sein, sonst gibts definitiv irgendwann Probleme.

    Aber ich muss mal testen, ob das in der Praxis auch so gut klappt.



  • Falls du ohnehin schon Git verwendest, schau dir auch mal git-annex an. Das verwende ich gerade für diverse Git-Repos, wo ich auch größere Files reinpacken möchte, ohne den Dateiinhalt selbst zu versionieren. (Wenn dir Git neu ist, lass git-annex lieber vorerst bleiben. Ist zwar ein extrem vielseitiges und praktisches Tool, aber für Git-Anfänger IMO nicht sehr angenehm geeignet.)



  • Wenn du es nur rum schieben willst, dann schau dir torrent sync an.

    Grüße


  • Mod

    nman schrieb:

    Falls du ohnehin schon Git verwendest, schau dir auch mal git-annex an. Das verwende ich gerade für diverse Git-Repos, wo ich auch größere Files reinpacken möchte, ohne den Dateiinhalt selbst zu versionieren. (Wenn dir Git neu ist, lass git-annex lieber vorerst bleiben. Ist zwar ein extrem vielseitiges und praktisches Tool, aber für Git-Anfänger IMO nicht sehr angenehm geeignet.)

    Warum stopfst du das große File nicht auch ins Repo?

    MfG SideWinder



  • Ich vermute mal weil das Diffen von grossen Files gross Zeit braucht 😉



  • hustbaer: Eigentlich gar nicht so sehr, gedifft wird ja kaum je.

    Side: Primär deswegen, weil die großen Files oft zwar irgendwie zum Repo dazugehören, aber nicht unbedingt rein müssen und das Repo nicht aufblähen sollen. Selektiver Sync ist auch sehr praktisch. Für meine Diplomarbeit hatte ich zum Beispiel Berge von Papers und ein paar sehr fette Ebooks, die ich im selben Repo wie meine Diplomarbeit haben wollte, aber nicht ständig immer und überall brauche. Mit annex braucht das "git clone" nicht länger und ich kann mir die Files trotzdem jederzeit holen, wenn ich sie haben möchte.

    Ein ehemaliger Kunde der viel mit Videomaterial macht hat zB. auch diverse Testvideos, die aktuell irgendwo am Fileserver herumliegen, weil sie so fett sind. Mit git-annex könntest du sie direkt in ein Verzeichnis im Repo packen, ohne dass der Inhalt versioniert wird oder bei jedem Klon dabei wäre.

    Für eine alte Vorlesung, wo ich demnächst ein paar Einheiten interessebedingt wieder durcharbeiten möchte, habe ich die Vorlesungs-Videos auch gleich in mein Repo gepackt. Am Server liegen sie damit und wenn ich sie lokal haben möchte geht das mit "git annex get file/bla/blubb.mp4".

    Mit einer Kollegin teile ich mir ein gemeinsames Paper-Repo, das mittlerweile ein paar Gigabytes groß ist (auch aufgrund von selbstgescannten Büchern uä.). Wenn ich das alles immer lokal herumliegen hätte, würden a) die Pulls lange dauern und bräuchte ich b) jetzt sofort eine neue SSD für meinen Laptop. 😉



  • nman schrieb:

    hustbaer: Eigentlich gar nicht so sehr, gedifft wird ja kaum je.

    Nicht bei jedem Commit wo das File geändert wurde?



  • Werden große Dateien wie z.B. *.tiff oder *.fbx nicht eh nur auf Änderung der Größe versioniert? (Standard mäßig)



  • Würde mich sehr wundern, denn das würde bedeuten dass man z.B. Datenbank-Files (SQLite etc.) nicht brauchbar versionieren könnte. Die sind nämlich sehr oft gleich gross nach einer Änderung.

    SVN prüft bei Binärfiles (bzw. vermutlich bei allen Files) AFAIK immer das "last write date". Und wenn sich das "last write date" geändert hat, dann wird nochmal die ganze Datei verglichen. Wenn dann wirklich ein Unterschied gefunden wird, dann gilt das File als geändert und wird mit committed. Wobei dann nochmal ein xdelta gemacht wird.

    Ich würde annehmen das GIT das selbe macht. Also zum feststellen was sich geändert hat, ob GIT auch xdelta verwendet weiss ich nicht.



  • gitter: Nein, das wäre sehr schlecht, die Heuristik ist deutlich komplizierter. (edit: Und wird nur dafür verwendet, möglichst wenige unnötige Checksummen-Berechnungen zu machen. Im wesentlichen werden viel Felder von lstat(2) verwendet.)

    hustbaer: Ich weiß die genauen Interna nicht auswendig, aber IIRC difft Git auch dann nicht, wenn es die mtime-Checks etc. (Inode, Größe, usw.) nahelegen, dass sich die Datei geändert haben könnte, sondern sieht sich den SHA1 an. Geringfügig billiger als ein Diff, ließe sich aber im Bedarfsfall auch mit "assume unchanged" umgehen, wo man dann nur bei Änderungen den Index manuell aktualisiert.

    Bei Commits wird auch nicht gedifft; nur beim Repack wird zum Platz sparen Herumkomprimiert (das ist dann natürlich schon delta compression). Ich glaube schon, dass Git bei großen Files irgendwann auch in die Knie geht, aber in der Praxis war das für mich noch nie ein Problem – besonders noch nie so ein großes wie mit den Vesionskontrollsystemen, die ich vorher verwendet habe.



  • nman schrieb:

    Bei Commits wird auch nicht gedifft; nur beim Repack wird zum Platz sparen Herumkomprimiert (das ist dann natürlich schon delta compression).

    OK, das verschiebt den Aufwand auch nur 🙂
    (Wobei es natürlich nett ist wenn man nicht beim committen warten muss, sondern die Angelegenheit wenn man möchte per cron/... über Nacht erledigen lassen kann!)

    Wie werden eigentlich Änderungen remote übertragen? Also wenn man nen Pull macht - keine Ahnung wie das in GIT-speak genau heisst ("SVN update" halt).

    Full Download?
    rsync?



  • hustbaer schrieb:

    OK, das verschiebt den Aufwand auch nur 🙂
    (Wobei es natürlich nett ist wenn man nicht beim committen warten muss, sondern die Angelegenheit wenn man möchte per cron/... über Nacht erledigen lassen kann!)

    Ja, einerseits das und andererseits lässt sich das auch extrem gut konfigurieren. Bei jedem Aufruf kannst du einstellen, wie viel Zeit die Delta-Compression brauchen darf, wie groß die Suchtiefe ist und und und. Der Cronjob darf dann zB. viel länger brauchen als dein Laptop oä. Dass überhaupt Packfiles angelegt werden, ist eine reine Optimierung; an sich könnte man das auch komplett weglassen.

    Wie werden eigentlich Änderungen remote übertragen? Also wenn man nen Pull macht - keine Ahnung wie das in GIT-speak genau heisst ("SVN update" halt).

    Ja, "git pull". Wenn du es genau wissen möchtest, lies am besten selbst nach; ganz grob funktioniert es bei Pulls ungefähr so (hoffentlich nicht zu sehr vereinfacht):

    • Git holt sich die SHAs aller Branches am Remote.
    • Git checkt, welche Objekte lokal schon vorhanden sind (SHA) und erstellt eine Liste von Objekten, die es gerne vom Server hätte.
    • Git sagt dem Server, welche Objekte es schon hat und welche es noch braucht.
    • Der Server antwortet dem Client mit einem passenden Packfile, in dem genau die fehlenden Objekte enthalten sind.

    Früher gab es einen recht primitiven Commit-Walker, der im wesentlichen rekursiv referenzierte Objekte geholt hat, die lokal noch nicht vorhanden waren. Problem dabei war, dass man bei großen Repos entweder große Mengen von losen Objektfiles einzeln herunterladen musste, oder aber ein paar wenige fette Packfiles herunterladen musste, auch wenn man nur wenige Objekte davon wirklich noch nicht hatte.


Log in to reply