Re: [Gnu-arch-users] Re: Maintaining private changes with upstream tarball releases?

[Marius Kjeldahl]

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.
=dev-lang/python-2.3*

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:

project--upstream--2.0.8
project--upstream--2.0.9

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:

project--myfeatureX--2.0.8
project--myfeatureY--2.0.9

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

project--myfeatureALL--2.0.8
project--myfeatureALL--2.0.9

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.

Regards,

Marius Kjeldahl