[GRASS5] Local support of stable and development versions

GRASS GRASS developer
1

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

2

John Harrop wrote:

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.

For use, you can freely move the install directory ($GISBASE); the
only place which should need to be changed is the "grass5" script
itself.

For compilation (using the normal "gmake5" mechanism), if you want to
move the source tree, you need to first do "make distclean". The
gmake5 and gmakelinks5 scripts contain fixed paths.

If you want to make multiple builds from a common source tree, look at
the alternate build mechanism (see mk/README). This should allow you
to build from a read-only source tree (once the makefiles have been
generated), and without interfering with other builds from the same
source tree.

For downloading, you can save bandwidth by copying an existing source
tree then updating to a specific version with "cvs update -r ...".

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?

Sharing the installation should be mostly harmless. AFAICT, the locks
directory is only used for digitisers (i.e. v.digit), or if the
monitors were built to use FIFOs instead of sockets.

As for sharing databases: you must own the mapset which you select in
the startup screen, and a single user can't run multiple GRASS
sessions on the same system. So, sharing databases should be safe
provided that you have a single UID space across all systems (e.g.
using NIS or synchronised /etc/passwd files), and a single user
doesn't attempt to run multiple concurrent sessions on multiple
systems using the same mapset.

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.

Local changes shouldn't be lost by "cvs update".

"cvs update" operates by generating a diff between the current version
and the (unmodified) local version, then applying that diff to the
(modified) local version.

In the output of "cvs update", modified files are normally shown with
either of the code letters "M" (if no changes have been made to the
repository version, or if such changes were successfully merged) or
"C" (if a conflict occured when attempting to update the local copy;
i.e. if the patching operation failed).

If a conflict occurs, the resulting file will contain both versions of
the conflicting code, along with some markers.

--
Glynn Clements <glynn.clements@virgin.net>