Tracking an 'upstream' project released as tarballs

DeeJay smartgpx at gmail.com
Thu Dec 10 18:06:50 GMT 2009


Workflow scenario for tracking (in Bzr) an 'upstream' project released
as "*.tar.gz" tarballs?

I've followed links on the wiki to
http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html and
read that.

But it assumes that the local mirror of the upstream project is
maintained by a 'foreign' vcs.

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.

Emptying the upstream mirror prior to unpacking the new tarball,
either via the OS or via 'bzr remove', causes all manner of problems
associated with folders that get moved and renamed - quite ugly - so
is not a viable way to proceed.

Have other people encountered this, and what workflow did you decide on?



More information about the bazaar mailing list