Paul Kelly wrote: > I think all three of these options are feasible. Option 2 is starting to > appeal to me most. I thought of doing some research into Option 3, but > then I thought it isn't really necessary, that the mapset locking is > perhaps a bit over-protective. As far as I can think, it is possible to > run multiple sessions in the same mapset anyway, if you use WIND_OVERRIDE > or GRASS_REGION, so there is really no fundamental need to lock a mapset - > it's just an extra encouragement/nagging to enforce good working > practices. Or have I missed something?
You also need to ensure that you don't try to modify a map (etc) from two sessions concurrently. OTOH, even with two sessions using different mapsets, you can theoretically run into problems with one session reading a map which is being modified by the other session. But I have yet to hear of anyone actually being bitten by it. But, yes, WIND is the main issue, and WIND_OVERRIDE should deal with that (except that the wxPython GUI reads the WIND file directly, which is a pretty serious bug). The VAR file could potentially be an issue, as could the CURGROUP and CURSUBGROUP files. There may be other files which I have overlooked. Personally, I would like to see both WIND and CUR[SUB]GROUP moved into $GISRC. The database stuff in VAR should also be able to be overridden by $GISRC, with VAR being used as a fallback (similar to DEFAULT_WIND for the region). -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev