Tracking 3rd-party sources

Giorgos Keramidas keramida at ceid.upatras.gr
Mon Apr 30 07:00:51 CDT 2007


On 2007-04-30 10:56, Marcin Kasperski <Marcin.Kasperski at softax.com.pl> wrote:
> Well. I feel I am still not sure what is the preferred way to 
> track 3rd party sources in mercurial. Maybe you will put some 
> light? Which of the ideas below is best (or maybe another one)?
> 
> ** Problem description **
> 
> I want to track some 3rd party sources (and apply some patches to 
> them). Those sources are not kept in mercurial repo (or 
> subversion, or git, or CVS) - I obtain them by releases 
> (foo-0.1.0.tar.gz, foo-0.2.0-tar.gz, ...)
> Just the old 'tracking third-party sources scenario described
> for instance here: 
> http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_13.html#SEC103
> 
> (in fact, in some scenarios the original repository can be 
> accessible, but not necessarily I am interested in tracking 
> unofficial development)

> ** Solution 2 - slightly CVS like **
> 
> I keep separate mercurial repo (or maybe branch) for 3rd party 
> sources, and import every new release there. Repo with my 
> changes is separate, I pull to it from the other repo and 
> develop inside.
> 
> The problems here:
> 
> 1) Merge happens in the opposite direction - instead of trying to
> reapply my patches (and check whether they still are suitable) I am
> trying to merge upstream changes on top of my code. The decision like
> throwing out my patch is more difficult to implement (one must
> carefully reconsider what and where is to be removed).

Merges don't have to happen in the 'opposite' direction.

I keep a mercurial repository with binary drops of a thirdparty
application in one repository with the following set of steps:

    hg up -C old-import
    cd thirdparty/
    rm -fr foo/
    tar xzvf ~/dist/foo-1.1.tar.gz
    mv foo-1.1 foo
    hg addremove foo
    hg commit -m 'import foo-1.1' foo

where 'old-import' is the last import of vendor code in the
'thirdparty/foo' directory.

This gives me two 'heads', which I can see with:

    hg heads

To merge the local changes on top of the latest import, I can use:

    hg up -C local-tip
    hg merge

and this pulls in the 'foo-1.1' changes into 'thirdparty/foo' but it
gives preference (by virtue of the up -C head selection) to the local
changes I have made to the 'foo' component.

This creates a history in thirdparty/foo which looks like this:

    ----[1]----[2]----[3]------------[5]------------[7]----
          \                          /              /
           `-----------------[4]----+-------[6]----'

where [1] is the initial import, [2] and [3] are local changes to the
source of 'foo', [4] is a new virgin import of the sources of 'foo', [5]
is a merge of the local changes on top of [4], then [6] is a new import
of another virgin version of 'foo' and [7] is a remerge of the local
changes on top of [6].

> 2) For some reason I sooner or later accidentally 'hg push', or 
> start developing in incorrect repo

You can prevent accidental "hg push" operations with:

    [paths]
    default = /upstream/repo
    default-push = /nonexistent

This way trying to "hg push" will fail because /nonexistent does not
exist as a mercurial repository.



More information about the Mercurial mailing list