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