On Sun, Jun 03, 2012 at 09:25:43AM +0000, Robin H. Johnson wrote: > On Sun, Jun 03, 2012 at 08:31:43AM +0000, Duncan wrote: > > Micha?? G??rny posted on Sun, 03 Jun 2012 09:22:04 +0200 as excerpted: > > > > >> Even if only the files metatdata changes, that still adds a significant > > >> cost to an rsync. > > > I wonder when it will come to the point where git will be more efficient > > > than rsync. Or maybe it would be already? > > Handwavey guess, but I've figured git to be more efficient client-side > > for some time. Server-side I don't know about, but I've presumed that's > > the reason the switch-to-git plans haven't included switching the default > > for user-syncs to git. I expect user/client side, git would be more > > efficient already, but as I said, that's handwavey guesses. > No, the switch to git will NOT help users, it isn't more efficient. > > They will still be best served by rsync, for a couple of reasons: > 1. metadata cache is NOT available in Git.
Sidenote, and this is mildly insane, I'd thought about submodules for this; basically every rsync window, we dump the metadata into vcs, which devs can pull down and make use of. I've also not experimented w/ this workflow, so it could be batshit insane. Anyone game to experiment? ~harring
