[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: Maintaining private changes with upstream tarba
Re: [Gnu-arch-users] Re: Maintaining private changes with upstream tarball releases?
Fri, 12 Sep 2003 22:50:05 +0200
On Wednesday 10 September 2003 00:03, John Goerzen wrote:
> I find that it works best to keep a separate branch for upstream and
> only commit actual upstream changes on that branch. Then, use tla
> update or replay to merge those changes into your own development.
> You may find my program tla_load_dirs useful. It is designed to ease
> the import process in just these cases. It detects adds, deletes, and
> offers you a chance to handle renames before committing upstream
> changes. If your upstream rarely if ever adds or renames files, then
> this won't be of use to you.
I got your tla_load_dirs utility today, but I will probably not be able to use
it now. It seems it require python2.3, and while trying to install that
version on my "bleeding edge" Gentoo system (which has python 2.2.3), I read
the following warning about upgrading:
# <address@hidden> (29 Aug 2003)
# initial testing for python 2.3.x. do not unmask unless you
# are prepared for a non-working portage.
In short, it warns against upgrading to python 2.3 until portage (the Gentoo
version of a swiss army knife for keeping a system up to date) has been
upgraded to work with it. If portage gets hosed on a Gentoo system, you are
pretty much screwed... Anyway, just thought you might want to know if others
bug you about not being able to run tla_load_dirs.
As for your other comments, I guess you suggest something like:
where the version number exactly reflects the current release from upstream.
Since I am not able to use your utility yet, I will simply create a fresh
upstream version, extracting the upstream tarball and committing the
unmodified tarball in the upstream branch.
For my own patches, I will use:
(assuming I have "multiple independent features" I want to keep separate)
where the myfeatureX base0 versions are tagged from the upstream versions with
the same version number.
Then I could create my "super duper" version (including ALL features from the
various featureX/Y branches) typically using:
where I would typically bring in the patches from each "feature" by replaying
all the patches from the myfeatureX/Y branches. The base0 version of the
myfeatureALL branch would be the corresponding upstream version, and then
patches would be applied for each of the featureX/Y branches.
Does this sound like a sensible way to organize this kind of work?
Thanks for all the information so far.