Avery Pennarun [off-list ref] writes:
You can only fill up your disks if
you download tons of movies and/or create tons of VMs.
Right, but if you do so, managing your movies and VMs with Git would
be really bad idea. Typically, you don't want your backup system to
try to diff each movie with each other to save space.
Just make sure your backup/syncing software has an expiration
algorithm so you don't end up storing *all* the historical copies.
And this is where Git will be really bad. Removing past revisions
means editing history, and while Git knows how to edit history,
syncing after doing that will be terrible.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Thu, May 13, 2010 at 7:48 AM, Matthieu Moy
[off-list ref] wrote:
Avery Pennarun [off-list ref] writes:
quoted
You can only fill up your disks if
you download tons of movies and/or create tons of VMs.
Right, but if you do so, managing your movies and VMs with Git would
be really bad idea. Typically, you don't want your backup system to
try to diff each movie with each other to save space.
This problem is supposedly solved by the git-bigfiles project. bup
does things a bit differently, but works well when deduplicating
things like VMs and movies, even though it uses the git repository
format.
quoted
Just make sure your backup/syncing software has an expiration
algorithm so you don't end up storing *all* the historical copies.
And this is where Git will be really bad. Removing past revisions
means editing history, and while Git knows how to edit history,
syncing after doing that will be terrible.
Yeah, obviously an SCM doesn't really need history expiration
features, and git's transport protocols are optimized with the
assumption that expiration will never happen. bup uses a different
protocol so it won't have this problem (but bup doesn't have any
expiration features at all, right now). rdiff-backup, which I also
mentioned, is efficient in the face of expiration.
Have fun,
Avery