repo with patched external libraries, proper way to do
Giorgos Keramidas
keramida at ceid.upatras.gr
Sun Feb 13 08:02:26 UTC 2011
On Sun, 13 Feb 2011 00:00:49 -0500, David Manura <dm.list at math2.org> wrote:
> So, what's the recommended way to do this.... I have a repo that uses
> some external libraries. The external libraries could have my own
> patches applied. The upstream to these external libraries could be in
> various version control systems or just infrequently updated tarballs,
> and for the most part I don't care to track the full temporal history
> or even all the directories in the upstream. All I need are the
> particular snapshots of the files in the upstream that permit my own
> repo(s) to build, and that does not include the upstream's 10 years of
> commits, documentation files, and source files for platforms I don't
> use.
>
> A relatively direct approach is to import the particular files I need
> from the external libraries into subdirectories of the main repo. I
> could have a separate "upstream" branch that tracks the pristine
> sources of all these external libraries, and patches would be applied
> in the main branch. Any time I want to update the library, I can
> switch to the upstream branch, replace the sources (perhaps even by
> using the native revision control tool), do an "hg addremove" with the
> new sources, and then merge that back into the main branch.
I tend to prefer *this* approach, even for sources that I wrote myself
but in an unrelated repository. I often use different named branches
for each library's "upstream" branch, e.g.:
default - main trunk of development
vendor/libfoo - upstream drops of lib/libfoo sources
Then tags in the 'default' branch that point to specific imports:
import-libfoo-0.9
import-libfoo-1.0.1
import-libfoo-1.0.3p7
This makes it easy to see e.g. the local changes at the latest tip of
the default branch by typing:
hg diff -r import-libfoo-1.0.3p7:default lib/libfoo | less
Keeping the entire source in a single repository is a habit I have
acquired by working with FreeBSD for several years. Having one, central
place to look for the project's history (instead of a gazillion small
repositories, all looking vaguely similar and subtly different) makes me
feel safer.
More information about the Mercurial
mailing list