Re: RFC: Subprojects

On Mon, 16 Jan 2006, A Large Angry SCM wrote:

Daniel Barkalow wrote:
[...]

quoted

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'm talking about using "git status" on the main project, in case you're 
misunderstanding me. If you can manage the entire project with the build 
system, then you don't need git or any version control at all, aside from 
your build system. But you'd also lose the ability to use webgit, bisect, 
gitk, git log, and so forth on the project as a whole.

quoted

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.

If you accept a tag identifying the latest stable revision, then you might 
as well not bother. The point of revision controlling a project is to be 
able to reconstruct previous states. If you allow any event, especially 
outside, unrelated, events to change the reconstructed state for a 
revision, then this is not the case. Your normal debugging situation will 
be "It's broken, and I didn't change anything." because someone somewhere 
else changed something, and you have no record of what last worked. And 
you can obviously forget any hope of "git bisect" working.

	-Daniel
*This .sig left intentionally blank*