[GRASS-dev] testing results of r.watershed2 against old r.watershed

[Glynn Clements]

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 <glynn at gclements.plus.com>