Tracking 3rd-party sources

Marcin Kasperski Marcin.Kasperski at
Mon Apr 30 03:56:56 CDT 2007

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:

(in fact, in some scenarios the original repository can be 
accessible, but not necessarily I am interested in tracking 
unofficial development)

** Solution 1 - mercurial queues **

After reading mercurial book I decided that Mercurial Queues seem 
to be the solution. To some degree they work great: 

a) First import

mkdir fooo
cd fooo
tar xzvf .../foo-0.1.0.tar.gz; mv foo-0.1.0/* .; rmdir foo-0.1.0
hg init
hg add
hg commit -m 'Import of foo-0.1.0'
hg tag foo-0.1.0
hg qinit -c

b) Developing of my patches

hg qnew removing-bueee-bug
(hack hack)
hq qrefresh
hg qcommit

c) Next import

hg qpop -a
rm -rf *
tar xzvf .../foo-0.2.0.tar.gz; mv foo-0.2.0/*; rmdir foo-0.2.0
hg addremove
hg commit -m 'Import of foo-0.2.0'
hg tag foo-0.2.0

hg push -a
 (and conflict resolution if necessary)

If it is so nice, then what is the problem with this solution? In 
fact, there are two:

1) I feel that my code (code of the patches I develop) is not 
truly version controlled. qrefresh offers none of the 
functionality usual commit offers (prompting for description, 
showing changed files, ability to review diffs ...), qcommit 
shows me only that the patch file changed (and diffs of patches 
are not very readable)

{ Yeah, I would be probably happy if instead of having qrefresh 
and qcommit I could issue usual commit and have it saved to the 
patch if I am working in patch mode. Although this is rough idea 
only. Another could be to ban using qrefresh if queues are kept 
in repo, use qcommit only, and give it full normal commit 
machinery }

2) (maybe here I did not learn MQ enough) I repeatably find 
myself in situation when I want to develop sth not relevant to 
the patch (trivial example: add sth to .hgignore) while working 
on the patch. I should probably just do it and then omit while 
qrefresh-ing, but I repeatably forget that there are some files 
I do not want to put into the patch. 

{ Not sure what is the good solution here }

** 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 

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

3) Two repos are two repos, less pleasant to use.

(2 and 3 are probably to disappear once I learn how to use hg 

** Solution 3 - which I only sense **

I suspect that it should be also possible to track 3rd party 
without branches, using only tags and 
bundling/unbundling/transplanting/... where necessary. But I am 
not sure how exactly to do it.

Bottom side-line: in case we get to some reasonable conclusion 
here, chapter like 'Tracking third party sources' could be 
considered for mercurial book...

More information about the Mercurial mailing list