Re: Merges without bases

[Martin Langhoff <martin.langhoff@gmail.com>]

On 8/27/05, Daniel Barkalow <barkalow@iabervon.org> 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