vendor tracking design flow

[Greg Ward]

On 31 August 2012, Simon King said:
> 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

FWIW, I use a similar trick to Neal. One recommendation:

  hg addremove --similarity=75

to detect renames upstream. Then if your local patches affect renamed
files, everything just works.

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

Sounds like an opportunity to write an extension!

[Simon's idea]
> 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/* .

...which is fine until you realize that upstream has files starting
with '.'. Then you realize "oh I really want to move the directory,
not its contents", but you can't "mv vendor ." because . already
exists ... and you end up with the "fake clone by hardlinking .hg"
trick. Which works great, but it is a clever and non-obvious trick.

So there probably is a better way to do this, but AFAIK no one has
taken the time to make it {bullet,idiot}-proof... which would be an
fun little project.

       Greg
-- 
Greg Ward                                http://www.gerg.ca/