Consider including repo manifest -r output with distributed images
The Replicant build directories contain a git_versions.txt file containing git commit IDs from subprojects. (For example, http://ftp.osuosl.org/pub/replicant/sdk/replicant-4.0/0001/infos/git_versions.txt .) However, there doesn't seem to be a way to use this file automatically, for example to rebuild an image using the same versions of software than in the distributed image. It appears that the build instructions in e.g. SDKBuild produce a current version of most software in the image, and not the versions that Replicant distributes. (Because the Replicant manifest default.xml does not contain exact revision information for most of the subprojects.)
However, the repo tool appears to be able to generate a manifest containing the commit IDs: repo manifest -r -o mymanifest.xml
I assume that if this generated manifest was included in, e.g., the replicant/manifest repository as, say, sdk_4.0_0001.xml, then one could view the sources and/or rebuild this exact version of the SDK with: repo init -u git://gitorious.org/replicant/manifest.git -m sdk_4.0_0001.xml
(probably also with repo sync -m sdk_4.0_0001.xml, from what I understand of "repo help sync")
There is also a "smart tag" option in repo (repo sync -t), which seems to be designed for fetching a particular version (a "known good build" is the example the help uses), but it seems to require setting up something called a "manifest server" on the network that would respond to these kinds of queries. Storing manifests containing commit IDs in files seems to be a much simpler approach.
Another approach would of course be for Replicant to distribute the source code of each image along with the binaries, but the files are rather huge. (repo init + repo sync of replicant-4.0 takes about 21 gigabytes on disk right now. Although I guess you could distribute only the then-current version and not the revision history: a .tar.gz of everything except the .repo subdirectory is "only" 2.5 gigabytes, and I assume that it (or a shallow clone, repo init --depth=1) would be enough for rebuilding.)
(Disclaimer: I did not have time to test that the repo init/sync stuff actually works, but the generated manifest looked correct. Sorry for not testing properly, but I thought it would be better to write this bug report quickly, as I heard you may be producing new images in the near future, and it is difficult to create this versioned manifest afterwards if you modify or re-sync the build directory...)