[GRASS5] Local support of stable and development versions
johnh at sjgeophysics.com
Mon Mar 3 22:18:59 EST 2003
I would appreciate comments or advice on locally configuring and
supporting stable and development versions of grass. I'm curious how
other people who modify grass seperate stable/production versions from
I've been keeping a cvs updated source tree of grass on one machine,
building it there and exporting the installed directory tree by NFS to
other local workstations. (I plan on a second one like this on a node
on our cluster. Since the cluster runs a different version of Linux
than than the front end work stations I need to keep the build/installs
So far only I have been modifying grass source - for local purposes or
testing/fixing modules. I keep a second copy of the modified source so
next cvs update I don't get clobbered. I also keep a seperate copy of
the last 'working' binary for modules being modified in case I need to
back track in a hurry. Now two or three other people here are wanting
to make occasional modifications to grass modules and they want to be
able to run the current production version. So the version control and
configuration management has gotten a bit more risky.
To keep multiple copies of grass building and working:
1) Is it sufficient to untar snapshots in their respective directory
trees (say ~/src/grass-5.0-stable ~/src/grass-5.0-dev and
~/src/grass-5.1-exp), configure each tree with a seperate install path
(say /usr/local/grass5 /usr/local/grass5x and /usr/local/grass51) and
then make sure that links in /usr/local/bin make sense? (that is, make
sure there is a grass5 and grass5x pointing to the correct places.)
This seems to make sense to me, but I wanted to check with the gurus to
see if I was missing a dependency of some kind.
2) Using NFS mounts to share the installation seems to work well as long
as the /usr/local/bin links are made. Running seperate instances with
different projects/mapsets on different machines does not cause any
conflicts on the hosting machine. Am I missing anything with this?
3) cvs tends to clobber local changes if an update is done on a modified
directory. I'm not a cvs guru. Perhaps I'm missing a cvs option here,
but OTOH I'm fairly sure cvs cannot help much with version merging.
Keeping copies of locally modified modules in seperate locations allows
merging by ediff after a cvs update.
Thanks for comments,
More information about the grass-dev