Tracking an 'upstream' project released as tarballs

[James Westby]

On Thu Dec 10 18:06:50 +0000 2009 DeeJay wrote:
> In a situation where the project is released from time-to-time as a
> snapshot in a tarball, how should the mirror of the upstream source be
> maintained?
> 
> Unpacking the latest tar archive over the old one is effective at
> creating new files and 'updating' old ones, but has no way of removing
> pre-existing files that are no longer required. The least damaging
> aspect of this is simply that old disregarded files are kept
> cluttering up the place. There is just a small risk that a file might
> be there as a 'sentinel'  - for example to say "don't build for
> Windows if this file exists"; or it might be a .ini file with some
> now-inappropriate default settings.

   bzr import

from bzrtools can import tarballs and handles this. It will make the
branch exactly like the tarball though, so don't use it if you
have local modifications.

  bzr import http://.../<new-release-tarball>

will make your tree the same as that, and then you can commit it.

If you want local modifications then use two branches. Use a branch
where you only import the tarballs, then a second branch that you
merge in to.

In the pristine branch:

  bzr import ...
  bzr commit -m "New release"

then in the modified branch

  bzr merge <pristine-branch>

review the diff, fix the conflicts and commit.

Thanks,

James