How do people manage changes to common library files stored across mutiple (Mercurial) repositories?

Question

This is perhaps not a question unique to Mercurial, but that's the SCM that I've been using most lately.

I work on multiple projects and tend to copy source code for libraries or utilities from a previous project to get a leg up on starting a new project. The problem comes in when I want to merge all the changes I made in my latest project, back into a "master" copy of those shared library files.

Since the files stored in disjoint repositories will have distinct version histories, Mercurial won't be able to perform an intelligent merge if I just copy the files back to the master repo (or even between two independent projects).

I'm looking for an easy way to preserve the change history so I can merge library files back to the master with a minimum of external record keeping (which is one of the reasons I'm using SVN less as merges require remembering when copies were made across branches).

Perhaps I need to do a bit more up-front organization of my repository to prepare for a future merge back to a common master.

Answer 1

Three solutions, pick your favorite:

1. Put all projects into one repository.
2. Make a separate repository for shared code and different repository for each project.
3. One repository with Subrepositories: http://mercurial.selenic.com/wiki/subrepos, keep all common code in one subrepo and different subrepos for each project.

Copying actual files between repositories with no common ancestors will never be optimal as history is not preserved.

Answer 2

use the transplant extension

Answer 3

I'd recommend against your "copy the sourcecode" practice but use binary distribution for your custom libraries instead. These binaries are checked in along the sourcecode.

• reduces build-time
• no overhead of tracking changes in all copies of the library
• you can use different versions of the same library in different projects.

EDIT: And for the issue with "common" or "toolbox" libaries in general, read this post from ayende.