On 21-01-2012 23:44:18 +0400, Konstantin Tokarev wrote:
> Advantage: much faster emerge --sync

proof?

> 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 with a non-existing/hard upgrade
path that's going to disappear as soon as we no longer need our overlay


--
Fabian Groffen
Gentoo on a different level

22.01.2012, 00:55, "Fabian Groffen" <grobian@gentoo.org>:
> 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.

Funtoo was already mentioned; team of Calculate Linux reports that
after they switched to git for portage syncing, speed increased significantly.

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

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?

--
Regards,
Konstantin

21.01.2012, 23:57, "Peter Abrahamsen" <rainhead@gmail.com>:
I believe drobbins is working on abstracting the repository so it could in theory be accessed over HTTP.

I'm not sure I understand your point, however git through HTTP is slooooow.

--
Regards,
Konstantin

On 22-01-2012 15:13:07 +0400, Konstantin Tokarev wrote:
>
>
> 22.01.2012, 00:55, "Fabian Groffen" <grobian@gentoo.org>:
> > 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.


--
Fabian Groffen
Gentoo on a different level

22.01.2012, 16:43, "Fabian Groffen" <grobian@gentoo.org>:
> From what, rsync? *A developer's usage is different from a user's usage.

http://www.calculate-linux.ru/blogs/en/320/show


--
Regards,
Konstantin

A theme of this thread is that different solutions are appropriate for different use cases. This means abstracting the filesystem out and having emerge query a repository, which might be the filesystem, a RESTful service, a database, or something else:

- Accessing the tree (not a git repo) through HTTP would mean no need for syncing or local storage, which would be very handy for some embedded scenarios, as well as ephemeral ("cloud") virtual systems.

- Funtoo's portage can read files directly out of git pack files, saving a lot of disk space and inodes, among other advantages.

Of course, as Fabian points out, writing and vending these interfaces is an engineering and operational burden for whoever provides them. Git sync server farms can be made, but if GitHub's experience is any indication, it's not super easy.

On the development side, It makes a lot of sense to me that Gentoo developers (or the developers of whatever distribution) might want to use git in order to support more decentralized workflows, something more like how the Linux kernel is written. It might also ease the work of an enterprise or spin-off distribution that wants to maintain their own fork of the Portage tree with particular patches, keywords, or additional packages.

Even if it were so, rsync would probably be the most appropriate way for most end users to get their portage tree goodness. But I think drobbins' effort to support other use cases is very worthwhile.

Peter

On Jan 22, 2012, at 3:14 AM, Konstantin Tokarev wrote:

>
>
> 21.01.2012, 23:57, "Peter Abrahamsen" <rainhead@gmail.com>:
> I believe drobbins is working on abstracting the repository so it could in theory be accessed over HTTP.
>
> I'm not sure I understand your point, however git through HTTP is slooooow.
>
> --
> Regards,
> Konstantin
>