Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 16, 2006, 20:20 UTC
Message-ID: <Pine.LNX.4.64.0601161414080.25300@iabervon.org>
In-Reply-To: <43CBEF47.7050607@gmail.com>

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

Show 16 quoted lines

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

Show 9 quoted lines

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