vendor tracking design flow

[Neal Becker]

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

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Simon King]

On Fri, Aug 31, 2012 at 12:28 PM, Neal Becker <ndbe...@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?

Simon

[Neal Becker]

Neal Becker 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 <<<< This should be update vendor!

> 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

Sorry, there was a typo there (as Simon pointed out) - that should be update to
vendor branch, as I indicated with the <<<< above

[Johannes Totz]

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

[Greg Ward]

On 31 August 2012, Simon King said:
> On Fri, Aug 31, 2012 at 12:28 PM, Neal Becker <ndbe...@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/