On Thu, May 13, 2010 at 7:48 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> 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. 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html