Re: RFC: Subprojects

On Tue, 17 Jan 2006, Daniel Barkalow wrote:

Yes, there are real advantages to being able to tag a very specific version of a tree.

You can do it manually (ie tag the versions of everything used), but there's a real convenience to being able to say "I want the tree to look exactly as it looked for our internal test-release that we shipped as a pre-view to customer so-and-so".

You can do it with ad-hoc build rules inside a company, but the likelihood that they don't work all the time is pretty high. Somebody forgot to follow the right procedure, and had updated a sub-tree without marking it, and now you can't reproduce the problem that a customer has with a debug build, because you have no way to reproduce the exact binary...

It's why people tag every file for huge trees under CVS for a release, and accept why building a release may take hours. It's crazy, yes, but there are other projects than just the BSD's that have that "World" mentality, where they want every single program under _one_ umbrella, so that they can tag them all together.

Me, I think it's crazy engineering ("if you can't reproduce it with individual projects, you're not doing programming, you're doing Voodoo"), but it's something that some organizations simply require.

Now, it might be enough with a cogito approach of ".git/subprojects", and just _version-control_ it in the top-level project, but then you'd need to make sure that all the tools automatically update the version when they do a "pull" or a "commit" on a subproject. But then it almost boils down to "gitlink"s after all.

		Linus