On Sat, Nov 13, 2010 at 12:35 AM, Ray Rashif <schiv@archlinux.org> wrote:
On 13 November 2010 06:13, C Anthony Risinger <anthony@extof.me> wrote:
On Fri, Nov 12, 2010 at 3:56 PM, csgeek <csgeek@archlinux.us> wrote:
Somewhat related question....
I've seen a few places deploy git based build systems.
funtoo (re-implementation of gentoo's portage but git based) and the arch based that was linked above.
I'm just curious.. at some point wouldn't that just create excessive history that's not needed? Do you really care about PKGBUILD of something that's 2..3.... 5 years out of date?
what's excessive? your talking about 95%+ highly compressible text files, with highly differentiable change sets and relatively slow updates (vs. an active source code tree); i don't see any problems. it won't accrue much at all imo, even after several years (decades?), but i don't have numbers to back that up.
however it is possible to use grafting and other techniques to prune/drop history, and still work with the repo. git and the data model will evolve too; last time i checked there was specifications/steps toward integrating v4/v5 packfile format.
git does however, need a good library to bind to; the code right now is... ehm... yeah...
Then again.. if we could use something like that.. to checkout an old version of a package, that would be well worth it. One thing that was available in gentoo that I miss in arch is the ability to have 2-3 version of a package available.
yeah, you could get any PKGBUILD you needed, with ease, and diff then against anything else...
maybe even, dare i say, p2p share the immutable objects around...
Binary packages are not version-controlled.
i wasn't implying they were; the question/answers seem to be about PKGBUILDs and related. that said it doesn't mean they couldn't be. we history pruning and various other techniques, such a system could be constructed where users are not required to have every package ever built, only what they wanted, but other peers could maintain the history as far back as they wanted. when all peers drop a point in history, it is lost (but at that point it would seem no one cares) the binary packs themselves could also be unversioned, and only their (very strong) fingerprint maintained in the history.
You can retrieve older versions of PKGBUILDs from our Subversion repository. You can diff between revisions as well. For something so straightforward, GIT is no more helpful.
that was an obvious example. git's data model is very simple and flexible, svn is a convoluted piece of <insert>. with git i can target specific branches for any repository; i can munge history with ease and finesse; i can share object repositories with unrelated projects; i can use the hooking system to create automatic development/staging/production platforms for my team. i could go on for much longer, but this is a well trodden path. git gives you the flexibility to create that which has not yet been discovered.
PKGBUILDs don't get multiple commits by multiple contributors to the extent software projects do, where GIT would make sense.
they will in time my friend, if i get my way :-) this is a goal i am actively pursuing. git makes sense in all capacities; you don't need to be a kernel or display server to realize the extent it can simplify your development life. i use it every day. it rocks. C Anthony