1 |
On Sat, Dec 15, 2018 at 11:15 PM Alec Warner <antarus@g.o> wrote: |
2 |
> |
3 |
> [1] Rich talked about some downsides earlier at https://lwn.net/Articles/759539/; but while these are challenges (some fixable) they are not necessarily blockers. |
4 |
|
5 |
The thread has already touched on a few of those comments. Despite |
6 |
only six months elapsing since I wrote that email, #1 no longer |
7 |
applies, and it sounds like #4 may not be as much of a concern. As |
8 |
you've already stated #3 can be easily addressed - setting up a git |
9 |
mirror is very easy. |
10 |
|
11 |
I think #2 is more of a fundamental design difference that probably |
12 |
will never go away. If your tree is a year old then git WILL take |
13 |
longer and transfer more data than rsync. My guess is that it will |
14 |
also cost more IO server-side than rsync, but it probably will be |
15 |
cheaper in CPU. However, I bet that 95% of our users sync weekly or |
16 |
daily and in that use case it is going to go a lot faster, and |
17 |
probably be less mirror load as well, and it will be a TON less IO |
18 |
load on the client side. I'm not sure how much IO cost there is to |
19 |
git garbage collection - that might offset this in the common shallow |
20 |
clone scenario. |
21 |
|
22 |
I'd suggest that those with concerns give it a shot using Zac's |
23 |
suggested settings and see how it goes. Really all you have to do is |
24 |
delete your local repo and adjust your sync settings and resync. I |
25 |
think the local disk use is going to be the biggest source of user |
26 |
objection and I'm interested in what people observe here. |
27 |
|
28 |
-- |
29 |
Rich |