Re: Merges without bases

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Aug 27, 2005, 20:49 UTC
Message-ID: <Pine.LNX.4.63.0508271544100.23242@iabervon.org>
In-Reply-To: <46a038f90508262348b25d1c8@mail.gmail.com>

On Sat, 27 Aug 2005, Martin Langhoff wrote:

Show 10 quoted lines

> 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.

I'm thinking of cases like openssl, openssh, and libcrypto. Openssl and openssh both use libcrypto but not each other (looking at the ldd output, rather than packaging). However, it would be too much of a pain to work directly on libcrypto without working through some other package, because the library doesn't have its own applications. Furthermore, if you're doing much to libcrypto, you're likely doing it in the context of a particular application (say, for example, ssh needs a new cipher that isn't supported for SSL at the time). You'd want to make simultaneous changes to libcrypto to implement the new feature and to openssh to use it; neither can be validated until the other is written, which means that you'll have both projects checked out and dirty (in the cache sense) at the same time, and be building the using project.

It would also be good to be able to check in this whole thing through the version control system, rather than partially through a change to the build system. That is, if I change the included libcrypto, commit it, and commit the including openssh, the system as a whole should understand that I want to change which commit of libcrypto gets used. Similarly, it would be good to merge changes into the libcrypto used by openssh with the same procedure used to merge changes to openssh itself, including supporting non-fast-forward when there's a local version in use.

(Of course, currently, libcrypto is strictly part of openssl, because it would be too much of a pain with the present version control to make it independant, and openssh depends on openssl, despite not even linking against -lssl, because openssl got libcrypto first.)

Show 5 quoted lines

> 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.

Certainly, if it's sufficiently external to be in a different SCM it should be handled by the build system. Actually, if it's even nearly that external, it's probably going to be handled best by requiring people to go get it themselves.

I find it odd that you say that the standard approach is to have the build system fetch a version of the included package; my experience is that projects either just report (or fail to report) a dependancy on having the other package or they copy the project into their project. The former means they can't change it (which is generally good, unless it becomes necessary), while the latter causes update problems (c.f. zlib).

I think that Arch configurations and the CVS equivalent are, in fact, useless, but that this is only due to implementation being insufficiently clever, not due to the concept being inherently bad; I feel the same way about distributed development under Arch, which is really nice under git, so I have hope that something better could be done.

	-Daniel
*This .sig left intentionally blank*