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