1 |
On Wed, Aug 24, 2011 at 12:44:57AM -0400, Matt Turner wrote: |
2 |
> On Tue, Aug 23, 2011 at 10:30 PM, Donnie Berkholz <dberkholz@g.o> wrote: |
3 |
> > On 15:49 Tue 23 Aug , Lance Albertson wrote: |
4 |
> >> I think using the shortlog output is the sane solution otherwise you're |
5 |
> >> just replicating what you do in the commit. |
6 |
> > |
7 |
> > It's not replication if users continue to use rsync; they won't have |
8 |
> > commit info. |
9 |
> |
10 |
> Do we really want users to continue using rsync? Isn't git pull so |
11 |
> much faster? What's the downside of users using git directly? |
12 |
rsync is still being supported. There is NO size or bandwidth advantage |
13 |
to the users having Git, quite the opposite in fact, the users would be |
14 |
disadvantaged if we required them to use git. |
15 |
|
16 |
Size: The size of an rsync tree will ALWAYS be smaller than _ANY_ VCS |
17 |
checkout, because none of the VCS overhead will be present (no CVS/, |
18 |
.git, etc). |
19 |
|
20 |
Bandwidth: Along the same lines, rsync will always be able to use less |
21 |
bandwidth than Git, because none of the intermediate commits need to be |
22 |
transfered. This will be esp. evident as a user tree gets older (the |
23 |
amount of mtime/checksum metadata scales linearly with the size of the |
24 |
tree, not the age of the tree. The actual file content transfered scales |
25 |
linearly with the age of the tree). |
26 |
|
27 |
The only advantage to users with Git is for those where metadata |
28 |
operations on their local disk is slower than the equivalent index |
29 |
operations in git (mtime checks on cold cache causing lots of seek vs |
30 |
being able to read a single file). |
31 |
|
32 |
-- |
33 |
Robin Hugh Johnson |
34 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
35 |
E-Mail : robbat2@g.o |
36 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |