Hallo,
ich habe ein großes SW Projekt von 1GB auf dem Dateisystem (400MB
gepackt).
Davon habe ich 10 Kopien auf dem Rechner mit unterschiedlichen SW
Ständen.
Diese unterscheiden sich aber nur in einigen wenigen Source Files. Und
noch dem erzeugten Binary.
Ich würde gerne das Ursprungs-Projekt zippen (400MB). Von den
Folgeständen hätte ich aber gerne ein kleines Zip das jeweils nur die
geänderten Dateien in ihren Unterordnern enthält, die ich dann wieder
dem Kunden zur Archivierung zur Verfügung stellen kann. Am liebsten so,
dass ich zum Beispiel *.obj oder ähnliche ausschließen kann. Gibt es
solche Tools? Können das Difftools?
System ist Win10.
Gruß Oliver
um die unterschiede zwischen den dateien zu finden, kannst dir mal
freefilesync anschauen.
da kannst 2 ordner wählen, dateitypen definieren oder ausschliessen.
somit verwendest du wohl kein git oder subversion?
Oliver L. schrieb:> Von den> Folgeständen hätte ich aber gerne ein kleines Zip das jeweils nur die> geänderten Dateien in ihren Unterordnern enthält
Die üblichen Imager können ausser Voll-Backup auch inkrementelle Backups
machen, die nur die Änderungen gegenüber dem vorigen Stand enthalten.
Allerdings ist es dementsprechend aufwendiger, einen bestimmten Zustand
wiederherzustellen, weil man da alle Versionen nacheinander einspielen
muss.
Alternativ gibt es auch differentielles Backup, da braucht man nur die
ursprüngliche Komplettsicherung und die letzte Version. Das ist wohl das
was du dir vorstellst.
Georg
Adam P. schrieb:> somit verwendest du wohl kein git oder subversion?
Frag ich mich auch. Vom Prinzip her muss man Doubletten suchen und dann
über das Datum in Unterverzeichnisse sortieren. Dann halt manuell
committen. Das funzt aber nur wenn sich Dateinamen nie geändert haben.
Dateitypen kann man mit einem ignorefile ausschließen.
Selber Nutze ich Mercurial, ist imo am leichtesten zu lernen.
also wenn du nur unterschiede sehen wilst, dann ist git zu viel.
ich nutze ab und zu
virtual svn server
und
tortoisesvn
das ist recht easy und erfüllt sein zweck
Speicherplatz kostet doch nichts. Ich würde tatsächlich für jedes
Projekt eine eigene virtuelle Maschine benutzen, die eine
kompilier-fähige Umgebung inklusive Projekt bereithält. So kannst du
auch nach Jahren, das gleiche Build reproduzierbar (und dein Kunde auch)
erzeugen.
jibi schrieb:> eine eigene virtuelle Maschine benutzen
WTH?
hast du zu warm geduscht? ?
selbst wenn es nur 4 projekte im jahr sind, willst du jedes mal ein
ganzes virtuelles laufwerk mit OS speichern wollen?
4 * ca. 20GB = 80GB (inkl. IDE, compiler, usw.)
obwohl sich nur paar KB an quell code geändert haben?....
naja.... kann man machen, ist halt s*****.
Ich würde wohl git verwenden. Wenn du aber kein VC willst:
Bei COW / ROW Dateisystemen, wie z.B. btrfs, zfs und xfs, kann man
identische Dateien Deduplizieren. Das funktioniert auf Blockebene
ähnlich wie Hardlinks, nur dass die Dateien für den User quasi
unabhängig bleiben / bei Bedarf kopiert werden.
Ordnerinhalte vergleichen kann man mit `diff` machen (gewisse Dateien
excludieren, nur Namen anzeigen, und vieles mehr, ist damit kein
Problem, zumindest mit der Variante die ich hier habe.). Einfach in der
Manpage (`man diff`) nachsehen.
Adam P. schrieb:> jibi schrieb:>> eine eigene virtuelle Maschine benutzen> ...> selbst wenn es nur 4 projekte im jahr sind, willst du jedes mal ein> ganzes virtuelles laufwerk mit OS speichern wollen?
Dass kann man mit dem guest geshartem COW / ROW Dateisystemen auch
lösen. Ich nehme wo möglich aber lieber Container, weniger Overhead.
Overlays gingen wohl auch, finde ich aber für sowas eher unpraktisch.
Ein Nachteil von VC und COW gegenüber separaten vollständigen Kopien ist
aber die geringere Redundanz.
jibi schrieb:> würde tatsächlich für jedes Projekt eine eigene virtuelle Maschine> benutzen,
Er hat aber nur ein Projekt.
? DPA ? schrieb:> Ein Nachteil von VC und COW gegenüber separaten vollständigen Kopien ist> aber die geringere Redundanz.
Die gibt es doch schon. Außerdem lassen sich per Versionskontrolle
redundate Backouts erzeugen wie man lustig ist.
> Dass kann man mit dem guest geshartem COW / ROW Dateisystemen auch> lösen.
Am besten noch auf nen Bündel virtueller Maschinen. (Mein Beitrag zum
Wettbewerb der kompliziertesten Lösung ;-).)
Toby P. schrieb:> Selber Nutze ich Mercurial, ist imo am leichtesten zu lernen.
Subversion kann man ohne Server ausprobieren. Als "Zentrale" kann auch
einfach ein Verzeichnis dienen. Geht das auch mit Mercurial?
Ich empfehle dazu die GUI von Tortoise.
Unterschiedliche Dateien kannst du z.B. mit WinMerge finden.
>selbst wenn es nur 4 projekte im jahr sind, willst du jedes mal ein>ganzes virtuelles laufwerk mit OS speichern wollen?
Jein. Informiere dich mal über Docker, (git kenn ja die meisten) und
composer. Damit beschreibst du einfach deine Umgebung, checkst die im
git ein und kannst die jederzeit beliebige branches aus dem repo bauen,
deployen what so ever. auch mit integrationstest etc.
>Am besten noch auf nen Bündel virtueller Maschinen. (Mein Beitrag zum>Wettbewerb der kompliziertesten Lösung ;-).)
Ja einfach ist das nicht. Aber ich wollte nie wieder eine komplexere
Webanwendung wie früher "bauen". Mit composer Kinderspiel.
Bei Git einfach die Console benutzen, bis die Befehle sitzen -> das
hilft auch ungemein das Staging etc zu verstehen.
Eigentlich brauchst du erstmal nur:
git init
(git clone)
git add .
git commit -m "bla bla"
git status
git diff
mit dem TotalCommander geht sowas bequem und übersichtlich.
Aber Versionsverwaltung ohne git o.ä.? Nimmerwieder. Auch für git gibt
es zig grafische Oberflächen (auch den TotalCommander mit TortoiseGit).
Es geht ohne Server, aber mit braucht der Gegner nur ein 'pull' machen
um den Stand zu aktualisieren, das diff bildet git dann und macht den
download effizient.
jibi schrieb:> kannst die jederzeit beliebige branches aus dem repo bauen,
Bis jemand das "repo" abschaltet. Die Besitzer von Internet-Radios
wissen, wovon ich rede.
Ich habe in 5 Jahren schon zweimal die Abschaltung von Maven
Repositories erlebt, die ich brauchte. Und ich pflege Programme, die zum
Teil älter als 20 Jahre sind. Da wird man, was solche externe
Abhängigkeiten angeht, sehr vorsichtig. (Tipp: Sonatype Nexus als
cache+proxy nutzen)
