[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFR: GIT Package VCS

On Fri, 2007-06-08 at 07:13 -0400, Jesse Keating wrote:
> On Friday 08 June 2007 06:59:08 Josh Boyer wrote:
> > That then begs the question as to why we can't have a simple 'make
> > explode' target.  Or why people can't do 'make sources' + untar
> > themselves, or run rpmbuild -bp..
> Well, untar every time and then check into an SCM to bang against may not be 
> efficient.  You want the source already there and some history with your 
> patches so that the patch management system can work if you so choose to use 
> it.

But if you're doing that much development against this code base, isn't
it likely that you already have upstream's SCM repo checked out
somewhere?  Which you could then use for patch management...  And which
also encourages people to shove their changes back.

Maybe what you're saying for things like the Fedora kernel makes sense.
Where you have more than one or two packagers constantly dealing with
updating patches, etc.

> > For the vast majority of packages, I don't think having an exploded tree
> > in the SCM helps anything.  And it simply adds more overhead for those
> > packages.
> What I envisioned is when you imported a new source it would take care of 
> updating the optional exploaded directory for you.  When a maintainer checks 
> out a module from the package scm they get patches/spec/sources file per 
> usual.  They could optionally ask to get the exploaded tree for more indepth 
> work, but it would be an optional thing.

So thinking in SCM terms, you'd need the 'checkout' to not pull down the
exploded sources by default.  I'm not sure of an easy way to do that
with git at the moment.  Maybe hg can already do stuff like that?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]