On 20:55 Sat 06 Aug , Robin H. Johnson wrote:
> Everything you have mentioned here was previously covered in the
> discussions about Git conversion models. Please consult the history of
> this list, as well as the -scm list. Additionally, a large discussion
> about the pros and cons of all 3
On 8/8/11 7:42 AM, Andreas K. Huettel wrote:
> Am Samstag 06 August 2011, 23:57:13 schrieb Fabio Erculiani:
>> I really love the idea of being able to atomically push updates
>> across multiple CPVs. This is also what KDE, GNOME, and many other
>> teams are waiting for. Having multiple repos means
Am Samstag 06 August 2011, 23:57:13 schrieb Fabio Erculiani:
> I really love the idea of being able to atomically push updates across
> multiple CPVs.
> This is also what KDE, GNOME, and many other teams are waiting for.
> Having multiple repos means no atomicity and at this point, I would
> rather
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote:
> - tree generation is dynamic
> + easy to move packages around, their category is specified by the
> tree configuration, the repository the package lives in doesn't change,
> probably overlays, betagarden, graveyard, sunset,
On 07-08-2011 07:05:03 -0400, Rich Freeman wrote:
> What exactly are you thinking about here. How about this use case:
>
> I have a list of 150 packages/versions. I want to make all of them go
> from ~x86 to x86 at the same time.
>
> If they're all in one git repo, then I can use a script or wh
On Sun, Aug 7, 2011 at 5:12 AM, Fabian Groffen wrote:
> On 06-08-2011 20:55:05 +, Robin H. Johnson wrote:
>> Problems:
>> - atomic/well-ordered commits that span packages, eclasses and profiles/
>> directories. (Esp. committing to eclasses and then packages
>> afterwards).
>
> This can be
On 07-08-2011 11:21:51 +0200, Michał Górny wrote:
> Fabian Groffen wrote:
> > This can be done with a single commit to the rsync tree script, and it
> > doesn't necessarily need git repos.
>
> And have you considered the function PoV on this?
>
> With clean git repo: few commits, git push
>
> W
On Sun, 7 Aug 2011 11:12:47 +0200
Fabian Groffen wrote:
> > Problems:
> > - atomic/well-ordered commits that span packages, eclasses and
> > profiles/ directories. (Esp. committing to eclasses and then
> > packages afterwards).
>
> This can be done with a single commit to the rsync tree script,
On 06-08-2011 20:55:05 +, Robin H. Johnson wrote:
> On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote:
> > In this email, I step away from the current model that Gentoo uses for
> > the gentoo-x86 repository. Instead, I consider a repo-per-package
> > model, as in use by e.g. Fedo
On 06-08-2011 22:42:33 +0200, Krzysztof Pawlik wrote:
> To be honest I don't like that idea. I don't see any benefits from doing so:
> - tree generation is dynamic - actually I think this is a disadvantage, it
> has
> a nice potential to eat a lot of resources on master rsync server, also having
On 06-08-2011 16:17:32 -0400, James Cloos wrote:
> Your idea is a step in the right direction, but the ideal config would
> have a top level portage.git with sub-modules for each category, as well
> as for eclass, licenses, profiles and scripts. Each category.git should
> have sub-modules for each
On 07-08-2011 00:07:41 +0530, Nirbheek Chauhan wrote:
> On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen wrote:
> > In short, the repo-per-package model means that each package
> > (my-cat/package) is a separate repository in some VCS.
> > Instead of having a huge tree that will only grow forever (g
On 06-08-2011 16:36:00 +0100, Markos Chandras wrote:
> I like your proposal but please clarify the following two questions
>
> 1) Each package requires a new repository. Who is responsible to create
> that? Should developers be responsible to do that or they should ping infra?
I would prefer all
I really love the idea of being able to atomically push updates across
multiple CPVs.
This is also what KDE, GNOME, and many other teams are waiting for.
Having multiple repos means no atomicity and at this point, I would
rather prefer CVS (omg!).
--
Fabio Erculiani
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote:
> When we migrate away from CVS for gentoo-x86 (gx86), as it looks now,
> the same structure will be kept as we have in CVS now. Policies to
> reject merge commits and only allow rebases on e.g. the Git
> infrastructure will even more
On 06/08/11 16:13, Fabian Groffen wrote:
> There probably are drawbacks to this system as well. I, however, only
> see big advantages for the moment.
> Comments, thoughts, ideas welcome.
To be honest I don't like that idea. I don't see any benefits from doing so:
- history per package - huh? gi
Your idea is a step in the right direction, but the ideal config would
have a top level portage.git with sub-modules for each category, as well
as for eclass, licenses, profiles and scripts. Each category.git should
have sub-modules for each package therein.
Within the profiles.git it *might* be
Hey,
On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen wrote:
> In this email, I step away from the current model that Gentoo uses for
> the gentoo-x86 repository. Instead, I consider a repo-per-package
> model, as in use by e.g. Fedora [1] and Debian [2].
>
> In short, the repo-per-package model m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/06/2011 03:13 PM, Fabian Groffen wrote:
> All,
>
I think this post belongs to either -project or -scm MLs but anyway
> When we migrate away from CVS for gentoo-x86 (gx86), as it looks
> now,
I like your proposal but please clarify the follow
All,
When we migrate away from CVS for gentoo-x86 (gx86), as it looks now,
the same structure will be kept as we have in CVS now. Policies to
reject merge commits and only allow rebases on e.g. the Git
infrastructure will even more closely match the central and server-based
way of working Gentoo
20 matches
Mail list logo
