[GRASS5] Local support of stable and development versions

[Glynn Clements]

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 at virgin.net>