Gentoo Archives: gentoo-scm

From: Mike Auty <ikelos@g.o>
To: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Help?
Date: Thu, 06 Nov 2008 10:46:13
In Reply to: Re: [gentoo-scm] Help? by Donnie Berkholz
Hash: SHA1

Donnie Berkholz wrote:

Ah cool, thanks for that Donnie.  5:)  I agree with most parts (save
loading the final Options sections with two "Flat tree, 1 repo/package"
entries)...  5:P

Given that branching on a repo/tree will let people (by which I assume
we both mean developers?) fork off an individual package and then merge
it back into the tree with history, this doesn't seem to directly be a
pro of 1 repo/package.  Also, it's possible to fork off an individual
package and share it without uploading the whole repository by creating
a patchset from the branch, which I believe is how several kernel devs
work.  I can see the argument more for wanting to automatically post a
URL that will always be up-to-date though.

Another available option would be "Current tree, 1 repo/category".  It
would support some compression of duplicate ebuilds, would make package
renames simpler for non-category changes (are there any statistics on
whether moves are more often cross category?).  Having said that,
there'd also be many of the cons of the "1 repo/package" method
(duplication of history during cross-category moves, time for
development, complexity of deployment, shared directory problems, etc).

I was also wondering what people's thoughts were on branching?  Drobbins
appears to be using branching as a keywording method in Funtoo (mainline
for the main tree, another branch tracking the mainline for the Funtoo
experimental ebuilds).  I again imagine cons will outway pros
(especially given we already have a solid stable understood process for
keywording), but has this been considered?  Perhaps an rsyncable branch
for each arch, with the arch branches tracking mainline?  This would let
us prevent non ATs from being able to commit to stable trees.  The
ebuild simply gets written into the mainline (no KEYWORDS or anything),
ATs then pull the ebuild and associated files into the stable/unstable
branches as needed, and then even if changes are made to the original
ebuild later, they'd have to be explicitly pulled to make it back to
stable (and thus offer the chance of another pair of eyes).  Downsides
are, security fixes would require someone to check-in the fix to each
arch (costing time and effort).  Thoughts?

Mike  5:)
Version: GnuPG v2.0.9 (GNU/Linux)



Subject Author
Re: [gentoo-scm] Help? Alec Warner <antarus@g.o>
Re: [gentoo-scm] Help? Donnie Berkholz <dberkholz@g.o>