Hamish wrote: > Markus: > > > I have moved the code to GRASS 6.4.svn and 7.svn now and deactivated > > > the old version. > > Glynn: > > And presumably the clean-up I've done on watershed in 7.0 has all now > > been discarded?
FWIW, that was a rhetorical question. I resolved the issue with "svn remove raster/r.watershed2". > .... not fully - in devbr6 modifications need to me made to r.watershed2 > to keep the old option names: > - opt15->key = "slope_steepness"; > + opt15->key = "slope.steepness"; > > etc. so it has at least some of the grass7 changes. > > > actually I think it is wrong to call this r.watershed2 at all, really > after whitespace changes etc it is just some normal patches to r.watershed, > not a full rewrite of the module. I know, and ... > As such it should be merged into the old r.watershed code not get its own > new directory. A suggested way forward: indent and modify r.watershed2 > so that a minimal diff is created and apply that to r.watershed(1) keeping > an eye on option name changes and new unmerged developments. Note that any diff needs to be generated against the base version from which the updated version was forked, *not* against any existing version, otherwise you *will* end up accidentally discarding changes. Now, attempting to apply such a patch will probably generate a significant number of conflicts, given how much as changed in SVN since the fork. And resolving those conflicts is the responsibility of whoever decided to make these changes to a private copy instead of within SVN. On other (sane) OSS projects, it's taken for granted that updates are provided in the form of patches against the current (or at least recent) source tree. An update offered in the form of an entire modified copy based upon an old version of the tree would be rejected out of hand, not committed. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
