Subject: Re: Subprojects tasks

From: Martin Waitz <[email-masked]>
Date: Sat, 16 Dec 2006 23:58:10 +0100

hoi :)

Junio, I'll take a more detailed look at your mail tomorrow, after I
regenerated from all the Guinness I had tonight ;-)

On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
> Sven Verdoolaege <[email-masked]> writes:
> > On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> >> I suspect the hardest part is "rev-list --objects" (now most of
> >> it is found in revision.c).  [..]  But I think the updated
> >> code needs to know that "link" needs to be unwrapped and
> >> contained "commit" needs to be injected back to the ancestry
> >> walking machinery.

Well, I already got to the point of using the commit directly,
instead of any link object.  It even worked with rev-list --objects
in all my test cases.  That is, I could correctly clone/pack/pull
the complete project including all modules.

> > Wouldn't we then run into the scalability problems Linus was
> > concerned about ?

This is a real problem.

> If the plumbing layer does not have to (although I haven't
> thought it through, it does feel like it even shouldn't) unwrap
> "link" and let the Porcelain layer to deal with it, that would
> certainly make rev-list/revision.c part simpler.

Yes.  However, it makes other things more complicated.
If the plumbing does not do all the subproject stuff and you don't have
everything in one database it is much more difficult to really get
a consistent database when cloning or fetching (you have to get even old
submodule commits which are not reachable by the current supermodule
tree anymore, perhaps even submodules which do not exist anymore).

I did not have much time to think about these issues in the last day and
am not yet convinced on how to proceed,

-- 
Martin Waitz