Hamish: > >> Any thoughts on keeping the inter-branch svn merge > >> effort low?
Glynn: > > Don't merge? > > > > Eventually, 7.x and 6.x are going to diverge by more > > than just formatting. but forking isn't a very nice solution. Markus: > As suggested earlier: we re-indent both and the problem is > solved (agreed that 7.x and 6.x are going to diverge way more > in the future). and keep a log of any indent warnings. possible idea for automatic/internal/seamless "make mix" solution: use svn:externals http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html externals props can be slowly dropped from trunk/ as things diverge and are replaced. I am thinking here more of new module features added to devbr6 rather than library improvements, even though there will come a time when e.g. raster modules will all have to be ported to the new API. But when that happens it doesn't mean the vector modules all need to be dropped too. the ultimate goal here being to minimize developer overhead without hindering new development. ? Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
