vendor tracking design flow

[Johannes Totz]

On 31/08/2012 12:56, Simon King wrote:
> On Fri, Aug 31, 2012 at 12:28 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>> I'm pretty happy with my current flow.  The objective is to track an upstream
>> package, but apply a few of my own patches.
>>
>> Currently, I have 2 named branches:
>> vendor: (upstream)
>> default: (with my patches)
>>
>> With each new release of vendor-x.y.tar.gz, the flow is:
>>
>> tar xzf .... (extract new files, into directory vendor-x.y for example)
>>
>> cd default-repo (goto my current repo)
>> hg update default
>> cd ..
>> cp -al default-repo/.hg vendor-x.y
>> cd vendor-x.y
>> hg addremove
>> hg ci
>> hg update default
>>
>> I guess I'm just wondering:
>>
>> 1) Is there some 'better' way to accomplish this?
>>
>> 2) I'm a little bothered that it goes 'outside the system', using cp -al
>> blah/.hg.  It would be nice to have something entirely within hg, like:
>>
>> hg new-source vendor vendor-x.y.tar.gz
>>
>
> I would have thought the normal way to do this would be to add the new
> version on the 'vendor' branch, then merge it into default. Something
> like this (completely untested):
>
> # extract vendor files into new directory vendor-x.y
> tar xzf vendor-x.y.tar.gz
>
> cd yourrepo
>
> # switch to the vendor branch
> hg update vendor
>
> # remove all existing files and replace with the latest versions
> rm -rf *
> mv ../vendor-x.y/* .
> hg addremove
> hg commit -m 'add version x.y of vendor package'
>
> # Now switch back to the default branch and merge
> hg update default
> hg merge vendor
>
>
> Does that sound reasonable?

Works well for me.

I try to keep track of renames etc if it's not too much of a hassle, 
i.e. do a rename --after by hand. I have been bitten by the 
local-modified-but-remote-deleted-merge mess in the past...