From: Martin Langhoff Date: Sat, 27 Aug 2005 06:48:53 GMT Subject: Re: Merges without bases Message-ID: <46a038f90508262348b25d1c8@mail.gmail.com> In-Reply-To: On 8/27/05, Daniel Barkalow 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