| 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 |
Archives