On 22-01-2012 15:13:07 +0400, Konstantin Tokarev wrote:
> 22.01.2012, 00:55, "Fabian Groffen" <email@example.com>:
> > On 21-01-2012 23:44:18 +0400, Konstantin Tokarev wrote:
> >> Advantage: much faster emerge --sync
> > proof?
> Well... I realize that I should put some benchmark here, however
> I thought this is just a common sense. If you ever used git, you should
> know that e.g. if almost nothing has changed on remote (regular update),
> sync time will approach zero, but rsync always needs to iterate through
> all ebuilds to check if each file doesn't change separately.
robbat2 had some interesting stats on this that for the average user,
rsync will be actually more efficient.
> Funtoo was already mentioned; team of Calculate Linux reports that
> after they switched to git for portage syncing, speed increased significantly.
From what, rsync? A developer's usage is different from a user's usage.
> >> Possible migration path:
> >> 1) git init in master mirror of prefix portage tree
> >> 2) deliver files of initial .git repository via rsync
> > the prefix neither the main tree aren't even in git, so it would only be
> > artificial bloat that keeps history
> If you used git you should know that "bloat" is not significant. It's not SVN :)
I use git, and it stores history. This is the bloat I'm referring to.
> with a non-existing/hard upgrade
> > path that's going to disappear as soon as we no longer need our overlay
> Sorry, I haven't thought of it. Is there upgrade path from rsync btw?
No, neither is there one forseen as necessary.
Simple practical problem: we have rsync slaves now, but not git slaves,
neither can we turn them into git slaves.
Gentoo on a different level