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
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 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 no
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
On 07-08-2011 00:07:41 +0530, Nirbheek Chauhan wrote:
On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen grob...@gentoo.org 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
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 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 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. Fedora [1]
On Sun, 7 Aug 2011 11:12:47 +0200
Fabian Groffen grob...@gentoo.org 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
On 07-08-2011 11:21:51 +0200, Michał Górny wrote:
Fabian Groffen grob...@gentoo.org 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
On Sun, Aug 7, 2011 at 5:12 AM, Fabian Groffen grob...@gentoo.org 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
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
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,
-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 following
Hey,
On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen grob...@gentoo.org 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
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
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? git
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
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
19 matches
Mail list logo
