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

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?

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