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

[Glynn Clements]

Markus Neteler wrote:

> <glynn at gclements.plus.com> wrote:
> > And presumably the clean-up I've done on watershed in 7.0 has all now
> > been discarded?
> 
> No - since I didn't *replace* the old version.

If you add a near-clone of an existing directory and mark the old one
as "deprecated", then for all practical purposes you're replacing it.

If you want to keep both versions around, the correct solution is to
"svn copy" the existing version, and merge the changes into that.

All correct solutions involve merging. Any solution which doesn't
involve merging changes into the current version involves discarding
any work done since the code was forked.

This is the whole point of a version control system: being able to
branch the code then merge the branches back together again.

In that regard, anything which is a derivative of existing code
doesn't belong in grass-addons. If it's too radical even for 7.0, then
it should go into its own branch, so that SVN *knows* that it is a
branch of existing code.

> > If you're going to make "improvements" to a module, and you absolutely
> > must do so in private, outside of the SVN repository, at least make
> > the effort to merge in other people's changes instead of just throwing
> > them away.
> 
> Well, I disactivated the existing code in the Makefile and didn't remove
> any of your changes. I also consider(ed) GRASS 7.svn to be under
> development where things may be temporarily in a "fluent" state.

Things may temporarily fluent, but the changes are permanent.

> In generally I agree, in an ideal world with all being ideal developers
> in such a project only perfect code flows in. Unfortunately I don't meet
> these requirements.
> 
> Apologies if I upset you - will concentrate on GRASS 6 for now.

A better solution would be for developers to forego the instant
gratification of making additions available now (6.4) in favour of the
long term (7.0).

The focus on the short term has been the bane of GRASS for as long as
I've been around. The desire for quick fixes and workarounds is the
main reason why we now have two separate development branches, because
it's going to take so long to implement all of the substantial changes
which have been postponed over the last ten years or more.

-- 
Glynn Clements <glynn at gclements.plus.com>