[GRASS5] Local support of stable and development versions

[John Harrop]

Hello Developers,

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 
testing/development versions.

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

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,

John Harrop