I'm trying to figure out the sensible way to add Michael Barton's new tcltkgrass scripts to the 5.3 source tree, and need input.
It could be done by (at least):
(1) add tcltkgrass4/ under src and change the compilation list to point to this one instead of tcltkgrass ("à la" r.mapcalc3) - backwards compatible but adds more redundant stuff to the source tree, or
(2) replace all the existing tcltkgrass
Out of those, option 2 seems more sensible, especially since we can just revert in CVS if anything went wrong, BUT now, since there are a lot of files that changed, do I just overwrite with Michael's files and commit, or remove the existing src/tcltkgrass/ altogether then add the new tcltkgrass4 and commit, or... some other combination?
Thanks - I volunteered to do this and then realized I wasn't sure what the best strategy is. A good CVS learning experience...
Scott
Hello Scott
On Sat, 1 May 2004, Scott Mitchell wrote:
I'm trying to figure out the sensible way to add Michael Barton's new
tcltkgrass scripts to the 5.3 source tree, and need input.
It could be done by (at least):
(1) add tcltkgrass4/ under src and change the compilation list to point
to this one instead of tcltkgrass ("à la" r.mapcalc3) - backwards
compatible but adds more redundant stuff to the source tree, or
(2) replace all the existing tcltkgrass
Out of those, option 2 seems more sensible, especially since we can
just revert in CVS if anything went wrong, BUT now, since there are a
lot of files that changed, do I just overwrite with Michael's files and
Do that but don't just commit without doing a diff first (cvs diff -u) and
thoroughly checking it that you haven't overwritten any recent changes to
the CVS etc.
See:
http://grass.itc.it/pipermail/grass5/2002-December/006816.html
I say this without being very familiar with tcltkgrass or knowing what the
differences are between the old and Michael's versions. You need to make
sure you're not removing any functionality that was there before etc. and
that the new version works as well as the old one. That is your
responsibility if you're committing the changes! 
The best way to work with CVS is to make the changes to files in a working
checked-out copy of the source tree. Dumping changed versions of files on
top of others (overwriting) and then committing is always awkward. But this
is easier said than done when merging in contributions made by others who
don't have CVS access.
Paul