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