Re: Merges without bases

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Aug 27, 2005, 06:48 UTC
Message-ID: <46a038f90508262348b25d1c8@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0508261150320.23242@iabervon.org>

On 8/27/05, Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 5 quoted lines

> 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