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

Hamish hamish_b at yahoo.com
Fri Nov 28 02:27:09 EST 2008


Hamish:
> > 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.

Glynn:
> 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.

working by hand to sync r.watershed2 in devbr6 with r.watershed v1 in
devbr6 (by changing r.w2 not r.w1), and forward merging any incidental
cleanups to r.w(1) in devbr6 to trunk. once the patch is minimal it will
be applied to r.w(1) in devbr6 then forward merged to trunk. Not touching
the version of r.w2 in grass-addons.

in devbr6, front/ is now sync'd, shed/ is unchanged, and I only just
started on ram/. Others please 'svn up devbr6' and continue... I'm out
of time for now. there seems to be a lot of cloned code between ram/
and seg/ which could be combined. But I think that is a job to do in
trunk after the 2->1 merge is complete.

 
> 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.

for r.w, not too much really, but enough to keep an eye on it.

> And resolving those conflicts is the responsibility of
> whoever decided to make these changes to a private copy instead of
> within SVN.

it turns out the addons fork was after the great indent of 2008, so the
whitespace issues are probably due to the author's tab settings in their
text editor? luckily it isn't as diverged as it could be.


Hamish



      



More information about the grass-dev mailing list