On 8/27/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote: > The problem with both of these (and doing it in the build system) is that, > when a project includes another project, you generally don't want whatever > revision of the included project happens to be the latest; you want the > revision of the included project that the revision of the including > project you're looking at matches. That is, if App includes Lib, and
Exactly - so you do it on a tag, or a commit date with cvs. With Arch, GIT and others that have a stable id for each commit, you can use that or the more user-friendly tags. The project pulling the libs has the makefile, and the makefile says 'pull library-foo revision xxx'. If a later revision yyy is known to work well, you update the makefile and commit it. Perfectly version controlled, no need for special purpose machinery ;) The good thing here is that a makefile will know how to handle the situation if the external lib is hosted in Arch, in SVN, or Visual SourceSafe. If your external lib is only available as a tarball in a url, you can fetch that and uncompress it too. Arch configurations are _cute_ but useless in any but the most narrow cases. I want my SCM to be a good SCM, but this kind of interop is better left to general purpose languages. Letting the build system do it seems to be 'best-practice' and the right thing to do. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
