Re: RFC: Subprojects

[A Large Angry SCM <gitzilla@gmail.com>]

Daniel Barkalow wrote:
[...]
> 
> 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.

> 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.

--