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

[John Goerzen]

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.

Get it from address@hidden/tla-load-dirs--head--1.0
at http://arch.complete.org/projects.

-- John

Marius Kjeldahl <address@hidden> writes:

> After reading through Tom's tutorial, section "Elementary Branches -- 
> Maintaining Private Changes", it is still not clear for me how to apply this 
> into practice in one situation I am looking at.
>
> In short, the software is released upstream as basic tarballs. The current 
> version is 2.0.8. I have patches that contribute various things for the 
> version I use. Some of my patches have already been accepted for future 
> releases, but others may remain private for an unknown amount of time. They 
> might still be interesting for other users, so I am planning to keep the 
> patches available for each new release of the software.
>
> So typically, I will do the following:
>
> * Extract the tarball
> * Apply my changes/contribution and keep the ability to release individual 
> patches for the individual changes/contributions.
>
> Any suggestions on how to organise these types of changes? Should I keep the 
> "clean" 2.0.8 version in mainline and create a branch for each of my 
> contributions (named "feature X", "feature Y" etc), or should I just create 
> one branch (named "my stuff") and doing fancy tla commands to get a changeset 
> for each feature (or possibly just say "it's all or nothing" to make it 
> simple to maintain for me).
>
> What is the best way of organising this? Should I just disregard the upstream 
> version numbers and just import them in mainline--0.1 (typically), using 
> "snapshot" type tagging for marking which revision in my mainline--0.1 
> version corresponds to which upstream version? Is it ok to use the actual 
> version names for the symbolic names (e.g. 2.0.8 etc..), or do I need to keep 
> track of which snapshot release corresponds to what 2.0.8 etc?
>
> But more importantly, how should I go about applying my patches when the next 
> version of the software is released as an upstream tarball (e.g. 2.0.9)? 
> Should I create a new version in mainline and put the 2.0.9 tarball there, 
> and how do I go about applying just my patches from my "development" 
> branch(es) from 2.0.8? Is it as simple as doing "replay" in the new 2.0.9 
> version and fixing stuff manually if replay fails?
>
> Any advice would be appreciated.
>
> Marius Kjeldahl
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/