Merging 3rd party updates which are not in a repository into my?repository

[Pierre Asselin]

doahh <gavin at prodia.co.uk> wrote:

> I have a web application that uses a MVNForum. My app uses mvnforum 1.1 and
> I have made modifications to it in order for it to have tighter integration
> with my app. MVNForum has now had a bug fix/security/upgrade release that I
> would like to merge into my app. Currently my forum project contains only
> the files from mvnforum that I have modified.

What if you could maintain an "mvnforum-incoming" hg repository
with the MVNForum releases and only the MVNForum releases ?  Then
you could clone and pull from that repository as if it were published
by the MVNForum people.  How you maintain your variants is "just"
normal Mercurial workflow and I don't want to get into that here :-)

Anyway, here's the idiosyncratic solution I came up with.
It relies on Mercurial implementation details but I floated
the idea in this list before and didn't get flamed.  (If
what I propose is dangerous I hope somebody will speak up.)

Create an empty repo.

    hg init mvnforum-incoming

Code drop:

    cd /anywhere/you/like
    tar xjvf mvnforum-1.1.tar.bz2
    cd mvnforum-1.1
    ln -s /path/to/mvnforum-incoming/.hg .hg
    hg addremove --similarity 70
    hg commit --message 'MVNForum 1.1'
    cd ..
    rm -rf mvnforum-1.1

All code drops are done the same way.  The mvnforum-incoming
repository holds a linear sequence of clean releases (initially
empty) and is always at the tip of said sequence (but no files
are checked out).  Planting the .hg symlink in a freshly unpacked
tarball turns it into a Mercurial sandbox with modified, added
and removed files, which can be committed as the new tip once
you've figured out the file renames.

The symlink trick is POSIX.  On Windows I guess you would
drag-and-drop the .hg subfolder under the tarball and
drag-and-drop it back after the commit (all under the
same drive letter so the DND is a move, not a copy).

Good luck.

-- 
pa at panix dot com