[Nut-upsdev] keeping branches in sync (was Re: [nut-commits] svn commit r1631 - branches/Experimental)

[Charles Lepple]

On Tue, Dec 16, 2008 at 9:57 PM, Charles Lepple <clepple at gmail.com> wrote:
> On Tue, Dec 16, 2008 at 3:27 PM, Arjen de Korte
> <adkorte-guest at alioth.debian.org> wrote:
>> Author: adkorte-guest
>> Date: Tue Dec 16 20:27:44 2008
>> New Revision: 1631
>>
>> Log:
>> Create an 'experimental' branch for changes that should
>> not be in the next stable release
>
> One potential problem with this is that it is easy for the branches to
> get out of sync with each other (some changes, e.g. the packaging
> removal in r1635, should be applied to both branches).
>
> I have used svnmerge.py at work for several months now, and it seems
> to be a decent way to keep several branches in sync (without forcing
> everyone to upgrade to Subversion 1.5, or switching to another SCM).
>
> Info: http://www.orcaware.com/svn/wiki/Svnmerge.py
>
> The script works by keeping track of previously merged ("integrated")
> and "blocked" revisions, stored as SVN properties. The "integrated"
> list prevents you from merging a change twice, if you let svnmerge.py
> drive the merge.
>
> There are several summary modes that would let you easily list commits
> which have not been merged e.g. from experimental to trunk. It is easy
> to set up the reverse relation, which would ensure that experimental
> has all of the trunk changes that make sense to merge.
>
> Thoughts?

If nobody has any objections, I will go ahead and set this up sometime
over the next few days.

The only drawback I can think of is that the repository will have a
few extra commits which are just property changes (to set up things
for future merges).

Also (and this is mostly for Arjen), should we build
branches/Experimental in Buildbot? Would it make sense to have two
boxes per platform - one for the trunk, and one for experimental?

-- 
- Charles Lepple