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