tracking third-party sources

[Pierre Asselin]

Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> On Sun, 4 Jan 2009 00:48:02 +0000 (UTC), Pierre Asselin <pa at panix.com> wrote:
> >
> > ... and perform all code drops as follows:
> >     tar xjvf foo-x.y.tar.bz2
> >     cd foo-x.y
> >     ln -s ../foo-incoming/.hg .      # clever !
> >     hg addremove --similarity 70

> Hi Pierre,

> No you are not being too clever.  At least not if you avoid the symlink
> hack.

Hmm, I was hoping the symlink would be legitimate, based in part on the wiki,
http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks#head-4305d99709ec9b5cdab457363c9b9ef72585e4de
which implies that the "mercurialness" is fully and exclusively contained
in the .hg/ .  If not a symlink, then maybe

    foo-x.y> mv ../foo-incoming/.hg .
    [ addremove, commit, etc. ]
    foo-x.y> mv .hg ../foo-incoming

I guess that's what I'm really asking:  is the wiki entry correct
about the .hg/ subdirectory and should that be documented officially.


> Then I cloned release/3.1 to release/3.2, updated to the tip of the 3.1
> repository and run:

>     % hg up -C tip
>     % hg revert -r null .               # 'remove' workspace files

>       ... extract top-3.2.tar.gz in current directory

This part can be hard to control.  I'm using hg to track the kernel
source tree as supplied by Gentoo.  The "extract" part is an "emerge
update", which unpacks the kernel.org tarball and applies patches,
leaving the tree where Gentoo decides, not where you want it.  I know I
can move the contents later, but the symlink was so much more
elegant.  It also lets me do the code drop as an unprivileged user;
root only needs to plant the symlink.


> I am not sure how well the symlink hack will work, but you can
> definitely use a single 'incoming' clone for importing upstream sources.
> It is, in fact, exactly what the vendor branches in CVS are used for.

Right.  I'm trying to streamline the use of the incoming clone.


> There is, however, one important deail about using addremove for code
> drops.  It may record too many file copies, even with large similarity
> percentage values (over 95%).

> After every 'addremove' I verified with 'hg diff --git' that there are
> no false copies.  Sometimes, when there are small files in the workspace
> and they have huge copyright notices but very little "real" content
> using --similarity 90 ends up recording a few false positive copies.
> These can be manually reverted after addremove, and recorded as a pair
> of separate 'hg add' and 'hg remove' operations.

Good point.  Thanks.


-- 
pa at panix dot com