info and man pages in mercurial

I assume you build within the source tree. Prefer VPATH-builds
and the issue of overwritten *.1 and *.info files will go away.

The version labeling, e.g. "enblend-4.1-123deadbeef", is completely
intentional; it distinguishes and (almost) uniquely identifies
development versions. If you are fed up with it edit the file
"VERSION" in the project's root directory, set any version code you
want, re-generate the configuration files, and rebuild. BTW, this will
definitely happen when we shall prepare the next release. We shall
run through
    enblend-4.1rc1,
    enblend-4.1rc2,
    enblend-4.1rc3,
    ...,
and finally
    enblend-4.1.

No, I create a tarball and use this to create a rpm package in a clean mock chroot. Among other things this tests the full build from source, tests the dist target, and verifies all the dependencies. These snapshot packages get tested by people using the Hugin snapshots, so there are no surprises when the final release goes into fedora.

I can run `make dist` in a different directory using vpath, but it will still do a full build of the binaries even though they don't go in the dist target, this seems unnecessary.

The version labelling in the tarball name is fine if that is how you want to do it, the problem is that the tarball also includes a directory with this name. i.e. I can download the 'enblend-enfuse-4.0.tar.gz' file from sourceforge, but if I extract the files it creates a directory called 'enblend-enfuse-4.0-753b534c819d' rather than the expected 'enblend-enfuse-4.0'.

If you plan to change this string to (e.g.) 'rc3', then the result will be that the final 4.1 release tarball will contain a directory called 'enblend-4.1rc3' - Unless you change the string after the final release candidate, but usual practice is that the final release tarball is byte-for-byte identical to the final release candidate.

Hope this makes sense. I can cope with these things since I'm going to package enblend whatever, but if the source behaves in a 'normal' way then it vastly increases the chances of enblend getting into all the Linux/BSD distributions promptly.

If you can't stand how the automake-generated
"dist" target works, simply whip up your own.
Change all necessary "Makefile.am"; just make
sure you don't break existing functionality of
our build-system.

You have commit rights to the repo, so go ahead.

For extra points assign this issue to yourself
and put its ID in every commit-message of each
patch related to it.