Re: RFC: Subprojects

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Jan 16, 2006, 19:08 UTC
Message-ID: <43CBEF47.7050607@gmail.com>
In-Reply-To: <Pine.LNX.4.64.0601152248030.25300@iabervon.org>

Daniel Barkalow wrote: [...]

Show 8 quoted lines

> 
> So the problem with handling subprojects with the build system is that it 
> is too tempting to use the revision control system directly on the 
> subproject, at which point the thing you're developing and testing isn't 
> at all what other people will get if they check out your commit. You want 
> "git status" to report it as an uncommitted change if you have a different 
> revision of the subproject than your previous commit had, and it can't 
> tell if this information is buried in the build system.

Using "git-status" is the wrong tool to use there. What you should be using is "make project_status". Claiming "that it is too tempting to use the revision control system on the subproject" is wrong; you should use the SCM (of the subproject) to manage the subproject. You use the build system to manage the _entire_ project.

Show 6 quoted lines

> I like Linus's proposal: which revision of which project goes where is 
> part of the content, while how you manipulate data for that project is a 
> matter of local policy, and is not tracked, although it might be a good 
> idea to let project provide overridable defaults (so that, if you're a 
> random member of the general public and don't have a special method for 
> accessing the repository, you don't have to track it down yourself).

I think Linus' proposal is an attempt to solve the problem in the wrong place; it encumbers the SCM with features of limited applicability, that impose a specific methodology on how to handle subprojects, and requires that the SCM of the subproject be Git.

> The tricky question is whether we should permit the "subproject" objects 
> to specify a revision that isn't a hash, for use in identifying revisions 
> of subprojects in other systems.

Why would you want to limit how required versions of subprojects are specified? Your project policies and procedures may require that subprojects be specified by a subproject SCM specific immutable revision but the policies and procedures of other projects may not be so restrictive and could accept a tag identifying the latest "stable" (or something) revision.

--