On Tue, Dec 16, 2008 at 3:27 PM, Arjen de Korte
<adkorte-gu...@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

_______________________________________________
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Reply via email to