Re: rsync deprecated but promoted?

From: Petr Baudis <pasky@suse.cz>
Date: Sep 26, 2005, 13:32 UTC
Message-ID: <20050926133204.GB21019@pasky.or.cz>
In-Reply-To: <4d4586301dca616f42880612fae01492@cream.org>

Dear diary, on Sun, Sep 25, 2005 at 09:06:37PM CEST, I got a letter where Martin Coxall <quasi@cream.org> told me that...

Show 20 quoted lines

> On 25 Sep 2005, at 17:32, Zack Brown wrote:
> >Hi folks,
> >
> >When I use cogito, it gives a warning saying the rsync method is 
> >deprecated and
> >will be removed in the future. But when I visit kernel.org/git, the 
> >page says to
> >use an rsync URL with cg-clone.
> >
> >Maybe kernel.org should be updated?
> >
> 
> It does seem to be sending out a confusing message to us users too, 
> since an initial clone of Linus's tree with rsync is on my machine 10x 
> faster than an http clone, so it seems to be sending out something of a 
> confused/confusing message re: rsync.
> 
> Am I right in thinking it's because rsync didn't originally have pack 
> support, but now it does, Petr has simply forgotten to deprecate the 
> deprecation message?

Nope. rsync always did packs, I actually un-deprecated it for the time period when HTTP didn't. The thing is, rsync is bad - it will happily put duplicate, redundant, and especially unwanted data to your repository, especially when the shared GIT repositories happen. HTTP and git-daemon are much better access methods in this regard - actually, I still like HTTP the most:

+ Works everywhere - no special setup, no dedicated service, firewalls
and proxies won't stop it
+ Works properly, i.e. only getting stuff you want, unlike rsync
+ Replicates packs setup - would be even better if it would kill objects
and packs which the new pack makes redundant

	It would be best to have some smarter git-prune-packed, which
	would process just a single pack. The other alternative would be
	that it would prune packs being subsets of other packs as well,
	but that scaled bad. I will write another mail about that.

- It is slow. Actually, I think it should be much faster for incremental
fetches, and the initial fetch should take about the same time if you
use packs. But the question is, did we already hit the limit? Are we
using HTTP keepalive connections, do we parallelize the requests?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.