On Tue, Dec 16, 2008 at 9:57 PM, Charles Lepple <[email protected]> wrote: > On Tue, Dec 16, 2008 at 3:27 PM, Arjen de Korte > <[email protected]> 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
