Software Development (WG1) Version Control (T3) - Revision history

NeilArmstrong: Added glossary link to Configuration~

2012-10-11T00:52:33Z

Added glossary link to Configuration~

← Older revision		Revision as of 00:52, 11 October 2012
Line 353:		Line 353:
	Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.		Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

	Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B		Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional [[configuration~\|Configuration]] requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

NeilArmstrong: Added glossary link to Prompt~

2012-03-05T09:03:36Z

Added glossary link to Prompt~

← Older revision		Revision as of 09:03, 5 March 2012
Line 8:		Line 8:
	This is a description of how VistA development environments should be configured.		This is a description of how VistA development environments should be configured.

	<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.		<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M [[prompt~\|Prompt]], e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

	=== Theory ===		=== Theory ===

Ftrotter: trademark

2007-03-07T16:18:54Z

trademark

← Older revision		Revision as of 16:18, 7 March 2007
Line 1:		Line 1:
	== Setting up a VistA Development Environment ==		== Setting up a VistA Development Environment ==


			This page uses the historical meaning of the term "OpenVistA" [[VistA Trademark Issues]]

	=== Overview ===		=== Overview ===

166.102.160.132 at 22:04, 19 December 2005

2005-12-19T22:04:17Z

← Older revision		Revision as of 22:04, 19 December 2005
Line 101:		Line 101:
	</pre>		</pre>

	*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Here is the script <tt>install</tt>:		*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. When a development directory is created as a child of an integration environment, or as a child of another development environment, the command line switch <tt>--separate-globals</tt> can be used to specify that the child is to have its own global variables. Here is the script <tt>install</tt>:

	<pre>		<pre>
	#!/bin/bash		#!/bin/bash
	#		#
	# install - create new VistA environment as child of ~~current~~ environment		# install - create new VistA environment as child of an existing environment
	#		#
	# ~~This temporary version of the install script assumes that both~~		# Usage:
	~~# have the same GT.M version. Also, there is no error handling yet,~~
	~~# and no provision yet for a separate database on the child.~~
	#		#
	# ~~Set~~ up ~~standard environment to run VistA~~		# install [--separate-globals] newdirectory
			#
			# Limitations:
			#
			# 1. If the globals in the parent have a custom partitioning or a custom
			# partitioning is desired for the child, don't use this script.
			# 2. There is no error handling. Clean up by deleting the child manually.
			# 3. Parent and child must use the same version of GT.M.

			TRUE=0 # Symbolic constant(s)

			if [[ 0 -eq $# ]] ; then echo "Not enough information specified. Exiting." ; exit 1 ; fi

			case $1 in

			--separate-globals) # child gets own database
			separate=$TRUE
			child=$2
			;;

			*) # global variables are shared with parent
			child=$1
			;;

			esac

			if [[ -e $child ]] ; then echo $child " exists already. Exiting." ; exit 1 ; fi

	~~# Set up the environment for VistA~~
	pushd `dirname $0` 1>/dev/null		pushd `dirname $0` 1>/dev/null
	export parent=$PWD		export parent=$PWD
	source ./env		source ./env
	popd 1>/dev/null		popd 1>/dev/null
	echo "~~Parent is~~" $parent		echo "Creating environment in " $child " as child of environment in " $parent

	# Create the directory structure for the child		# Create the directory structure for the child
	mkdir -p $1/{g,o,r,p,tmp}		mkdir -p $child/{g,o,r,p,tmp}

	# Link the child to the parent		# Link the child to the parent
	ln -s $parent $1/parent		ln -s $parent $child/parent

	# Give the child the same GT.M version as the parent		# Give the child the same GT.M version as the parent
	ln -s $parent/gtm $1/gtm		ln -s $parent/gtm $child/gtm

	# Copy other files in this directory		# Copy other files in this directory
	find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $1/ \;		find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $child/ \;

			# Make run & cprs_direct executable in child; they may not be executable for the parent
			chmod u+x $child/run $child/cprs_direct
			find $child -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;
			find $child -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod g+x {} \;

	# ~~Make run & cprs_direct executable because it may not be executable for the parent~~		# Copy global directory
	~~chmod u+x~~ $1/~~run~~ $1/~~cprs_direct~~		cp $parent/g/mumps.gld $child/g/
	~~find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;~~
	~~find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod~~ g~~+x {} \;~~

	# ~~Give~~ the ~~child a~~ global directory, for ~~now the same as~~ the parent		# Several cases to consider with respect to the database and global directory for the child:
	~~cp $~~parent~~/g/mumps~~.~~gld $1/g/mumps.gld~~		# 1. Parent database is zipped: Child always gets unzipped database from parent
			# 2. --separate-globals is specified without any arguments: child gets copy of database from parent
			# 3. --separate-globals is not specified: Child shares database with parent; nothing to copy

	~~# Give the child a database~~		if [[ -e $parent/g/mumps.dat.gz ]] ; then # case 1 above
	if [[ -e $parent/g/mumps.dat.gz ]] ; then
	echo "Unzipping from parent to create initial database"		echo "Unzipping from parent to create initial database"
	gzip -d <$parent/g/mumps.dat.gz >$1/g/mumps.dat		gzip -d <$parent/g/mumps.dat.gz >$child/g/mumps.dat
	$gtm_dist/mupip set -journal="enable,on,before" -file $1/g/mumps.dat
	chmod o+r,o-w,g+w $1/g/mumps.{dat,mjl}		elif [[ $separate ]] ; then # case 2 above
	~~else~~		echo "Backing up copy of parent database to child environment"
	~~echo "Using parent database in this environment"~~		$gtm_dist/mupip backup DEFAULT $child/g/

			fi

			# Set up journaling for child
			if [[ -e $child/g/mumps.dat ]] ; then
			$gtm_dist/mupip set -journal="enable,on,before,file=$child/g/mumps.mjl" -file $child/g/mumps.dat
			chmod o+r,o-w,g+w $child/g/mumps.{dat,mjl}
	fi		fi

	# Make files except database files, journal files & directories read-only		# Make files except database files, journal files & directories read-only
	find $1 -type f \! -name \.dat \! -name \mjl -exec chmod a-w {} \;		find $child -type f \! -name \.dat \! -name \mjl -exec chmod a-w {} \;
	find $1 -type d -exec chmod 775 {} \;		find $child -type d -exec chmod 775 {} \;

	echo "Default permission for development environment is for all to read and group to write - please ~~fix if~~ needed"		echo "Default permission for development environment is for all to read and group to write - please alter as needed"
	</pre>		</pre>

Bhaskar: /* VistA Development Directories */

2005-11-22T20:04:30Z

VistA Development Directories

@@ Line 261: / Line 261: @@
 ==== VistA Development Directories ====
-A development directory is like an integration directory, except that it does not normally have its own database file or global directory.  However, as discussed above, it may be entirely appropriate for a development directory to have database files and global directories.
+A development directory is like an integration directory, except that it does not normally have its own database file or global directory.  Here is an example of creating a development environment from the integration environment:
 Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.
 Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M.  In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Bhaskar: /* VistA Integration Directories */

2005-11-22T19:56:23Z

VistA Integration Directories

← Older revision		Revision as of 19:56, 22 November 2005
Line 179:		Line 179:

	==== VistA Integration Directories ====		==== VistA Integration Directories ====

			Here is an example of creating an integration environment from a release environment:

			<pre>
			vista@Makaira:~$ /opt/FOIAVistA20051021/install LeonardoDaVistA0.1
			Parent is /opt/FOIAVistA20051021
			Unzipping from parent to create initial database
			%GTM-I-JNLCREATE, Journal file /home/vista/LeonardoDaVistA0.1/g/mumps.mjl created for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat with BEFORE_IMAGES
			%GTM-I-JNLSTATE, Journaling state for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat is now ON
			Default permission for development environment is for all to read and group to write - please fix if needed
			vista@Makaira:~$
			</pre>

	A VistA integration directory is similar to a VistA release directory, with the following differences.		A VistA integration directory is similar to a VistA release directory, with the following differences.

Bhaskar: /* VistA Integration Directories */

2005-11-22T19:50:25Z

VistA Integration Directories

@@ Line 186: / Line 186: @@
 *The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created.  A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)
-*A script <tt>run</tt> which invokes and runs VistA in that integration environment.  Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory.
+*A script <tt>run</tt> which invokes and runs VistA in that integration environment.  Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory.  Here is the <tt>run</tt> script:
 *When the <tt>install</tt> script is executed, it will create a development directory.
-*The normal protection on all directories and files in an integration directory should be read-only.  When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.
+*Except for database files, journal files, and directories, the normal protection on all directories and files in an integration directory should be read-only.  When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.
 ==== VistA Development Directories ====

Bhaskar: /* VistA Release Directories */

2005-11-22T18:15:34Z

VistA Release Directories

Show changes

Bhaskar: /* VistA Release Directories */

2005-11-22T17:45:50Z

VistA Release Directories

← Older revision		Revision as of 17:45, 22 November 2005
Line 72:		Line 72:
	*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.		*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

	*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Option <tt>--newgtm</tt> ''gtmver'', specifies that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption is that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> is used to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.		*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Option <tt>--newgtm</tt> ''gtmver'', specifies that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption is that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> is used to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled. Here is the script <tt>install</tt>:

	==== VistA Integration Directories ====		==== VistA Integration Directories ====

Bhaskar: /* VistA Release Directories */

2005-11-22T04:32:27Z

VistA Release Directories

← Older revision		Revision as of 04:32, 22 November 2005
Line 72:		Line 72:
	*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.		*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

	*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Option <tt>--newgtm</tt> ''gtmver'', specifies that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption is that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb<//tt> is used to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.		*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Option <tt>--newgtm</tt> ''gtmver'', specifies that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption is that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> is used to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

	==== VistA Integration Directories ====		==== VistA Integration Directories ====