Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
aegis -MoVe_file(1)	    General Commands Manual	   aegis -MoVe_file(1)

	aegis move file	- rename one or	more files as part of a	change

	aegis -MoVe_file [ option...  ]	old-file-name new-file-name [ old1
	new1 [ old2 new2 ... ]]
	aegis -MoVe_file -List [ option...  ]
	aegis -MoVe_file -Help

	The aegis -MoVe_file command is	used to	copy a file into a change and
	change its name	at the same time.

	The named files	will be	copied from the	baseline (old-file-name) into
	the development	directory (new-file-name), and added to	the list of
	files in the change.

	Warning: If there is already files in the development directory	of ei-
	ther the old-name or the new-name they will be overwritten.

	The old-file-name in the development directory will contain 1KB	of
	random text.  The random text is sufficiently revolting	that most com-
	pilers will give error messages, should	the file be referenced acci-
	dentally.  This	is often very helpful when moving include files.

	You may	rename directories.  All the files in the old-name directory
	tree will be renamed to	be below the new-name directory	tree.

   File	Name Interpretation
	The aegis program will attempt to determine the	project	file names
	from the file names given on the command line.	All file names are
	stored within aegis projects as	relative to the	root of	the baseline
	directory tree.	 The development directory and the integration direc-
	tory are shadows of this baseline directory, and so these relative
	names apply here, too.	Files named on the command line	are first con-
	verted to absolute paths if necessary.	They are then compared with
	the baseline path, the development directory path, and the integration
	directory path,	to determine a baseline-relative name.	It is an error
	if the file named is outside one of these directory trees.

	The -BAse_RElative option may be used to cause relative	filenames to
	be interpreted as relative to the baseline path; absolute filenames
	will still be compared with the	various	paths in order to determine a
	baseline-relative name.

	The relative_filename_preference in the	user configuration file	may be
	used to	modify this default behavior.  See aeuconf(5) for more infor-

   Process Side	Effects
	This command will cancel any build or test registrations, because
	adding another file logically invalidates them.

	When the change	files are listed (aegis	-List Change_Files -TERse) the
	new files (new-file-name) will appear in the listing, and the removed
	files (old-file-name) will not appear in the terse listing.  Simi-
	larly, when the	project	files are listed with an explicit change num-
	ber (aegis -List Project_Files -TERse -Change N) none of the change's
	files, including both the new and removed files, will appear in	the
	terse listing.	These two features are very helpful when calling aegis
	from within a DMT to generate the list of source files.

	The new_file_command and remove_file_command in	the project config
	file are run, if set.  The project_file_command	is also	run, if	set,
	and if there has been an integration recently.	See aepconf(5) for
	more information.

	Aegis provides you with	what is	often called a "view path" which indi-
	cates to development tools (compilers, build systems, etc) look	first
	in the development directory, then in the branch baseline, and so on
	up to the trunk	baseline.

	The problem with view paths is that in order to	remove files, you need
	some kind of "whiteout"	to say "stop looking, it's been	removed."

	When you user the aerm(1) or aemv(1) commands, this means "add infor-
	mation to this change which will remove	the file from the baseline
	when this change is integrated".  I.e. while the change	is in the be-
	ing developed state, the file is only "removed"	in the development di-
	rectory	- it's still present in	the baseline, and will be until	the
	change is successfully integrated.

	When you use the aerm(1) or aemv(1) commands, Aegis will create	a 1K
	file to	act as the whiteout.  It's contents are	rather ugly so that if
	you compile or include the "removed" file accidentally,	you get	a fa-
	tal error.  This will remind you to remove obsolete references.

	When the change	in integrated, the removed file	is not copied/linked
	from the baseline to the integration directory,	and is not copied from
	the development	directory.  At this time it is physically gone (no
	whiteout).  It is assumed that because of the error inducing whiteout
	all old	references were	found and fixed	while the change was in	the
	being developed	state.

   File	Manifests
	When generating	list of	files to be compiled or	linked,	it is impor-
	tant that the file manifest be generated from information known	by
	Aegis, rather than from	the file system.  This is for several reasons:

	(a) Aegis knows	exactly	what (source) files are	where, whereas every-
	    thing else is inferring Aegis' knowledge; and

	(b) looking in the file	system is hard when the	view path is longer
	    that 2 directories (and Aegis' branching method can	make it	arbi-
	    trarily long); and

	(c) The	whiteout files,	and anything else left "lying around", will
	    confuse any	method which interrogates the file system.

	The easiest way	to use Aegis' file knowledge is	with something like an
	awk(1) script processing the Aegis file	lists.	For example, you can
	do this	with make(1) as	follows:
		# generate the file manifest manifest.make.awk
		    ( aegis -l cf -ter ; aegis -l pf -ter ) | \
		    awk	-f manifest.make.awk >
		# now include the file manifest
	Note: this would be inefficient	of you did it once per directory, but
	there is nothing stopping you writing numerous assignments into	the file,	all in one pass.

	It is possible to do the same thing with Aegis'	report generator (see
	aer(1) for more	information), but this is more involved	than the
	awk(1) script.	However, with the information "straight	from the
	horse's	mouth" as it were, it can also be much smarter.

	This file manifest would become	out-of-date without an interlock to
	Aegis' file operations commands.  By using the project-file_command
	and change_file_command	fields of the project config file (see aep-
	conf(5)	for more information), you can delete this file	at strategic
		/* run when the	change file manifest is	altered	*/
		change_file_command = "rm -f";
		/* run when the	project	file manifest is altered */
		project_file_command = "rm -f";
	The new	file manifest will thus	be re-built during the next aeb(1)

   Options and Preferences
	There is a -No-WhiteOut	option,	which may be used to suppress whiteout
	files when you use the aerm(1) and aemv(1) commands.  There is a cor-
	responding -WhiteOut option, which is usually the default.

	There is a whiteout_preference field in	the user preferences file (see
	aeuconf(5) for more information) if you	want to	set this option	more

   Whiteout File Templates
	The whiteout_template field of the project config file may be used to
	produce	language-specific error	files.	If no whiteout template	entry
	matches, a very	ugly 1KB file will be produced - it should induce com-
	piler errors for just about any	language.

	If you want a more human-readable error	message, entries such as
		whiteout_template =
			pattern	= [ "*.[ch]" ];
			body = "#error This file has been removed.";
	can be very effective (this example assumes gcc(1) is being used).

	If it is essential that	no whiteout file be produced, say for C	source
	files, you could use a whiteout	template such as
		whiteout_template =
		    { pattern =	[ "*.c"	]; }
	because	an absent body sub-field means generate	no whiteout file at

	You may	have more than one whiteout template entry, but	note that the
	order of the entries is	important.  The	first entry which matches will
	be used.

	On successful completion of this command, the notifications usually
	performed by the aerm(1), aenf(1) and aent(1) commands are run,	as ap-
	propriate.  These include the project_file_command, new_file_command,
	new_test_command and remove_file_command fields	of the project config
	file.  See aepconf(5) for more information.

	The following options are understood:

	-Change	number
		This option may	be used	to specify a particular	change within
		a project.  See	aegis(1) for a complete	description of this

		This option may	be used	to obtain more information about how
		to use the aegis program.

		This option may	be used	to obtain a list of suitable subjects
		for this command.  The list may	be more	general	than expected.

		This option may	be used	to disable the automatic logging of
		output and errors to a file.  This is often useful when	sev-
		eral aegis commands are	combined in a shell script.

	-Project name
		This option may	be used	to select the project of interest.
		When no	-Project option	is specified, the AEGIS_PROJECT	envi-
		ronment	variable is consulted.	If that	does not exist,	the
		user's $HOME/.aegisrc file is examined for a default project
		field (see aeuconf(5) for more information).  If that does not
		exist, when the	user is	only working on	changes	within a sin-
		gle project, the project name defaults to that project.	 Oth-
		erwise,	it is an error.

		This option may	be used	to cause listings to produce the bare
		minimum	of information.	 It is usually useful for shell

		This option may	be used	to cause aegis to produce more output.
		By default aegis only produces output on errors.  When used
		with the -List option this option causes column	headings to be

	-Wait	This option may	be used	to require Aegis commands to wait for
		access locks, if they cannot be	obtained immediately.  De-
		faults to the user's lock_wait_preference if not specified,
		see aeuconf(5) for more	information.

		This option may	be used	to require Aegis commands to emit a
		fatal error if access locks cannot be obtained immediately.
		Defaults to the	user's lock_wait_preference if not specified,
		see aeuconf(5) for more	information.

		This option may	be used	to request that	deleted	files be re-
		placed by a "whiteout" file in the development directory.  The
		idea is	that compiling such a file will	result in a fatal er-
		ror, in	order that all references may be found.	 This is usu-
		ally the default.

		This option may	be used	to request that	no "whiteout" file be
		placed in the development directory.

	See also aegis(1) for options common to	all aegis commands.

	All options may	be abbreviated;	the abbreviation is documented as the
	upper case letters, all	lower case letters and underscores (_) are op-
	tional.	 You must use consecutive sequences of optional	letters.

	All options are	case insensitive, you may type them in upper case or
	lower case or a	combination of both, case is not important.

	For example: the arguments "-project", "-PROJ" and "-p"	are all	inter-
	preted to mean the -Project option.  The argument "-prj" will not be
	understood, because consecutive	optional characters were not supplied.

	Options	and other command line arguments may be	mixed arbitrarily on
	the command line, after	the function selectors.

	The GNU	long option names are understood.  Since all option names for
	aegis are long,	this means ignoring the	extra leading '-'.  The	"--op-
	tion=value" convention is also understood.

	The recommended	alias for this command is
	csh%	alias aemv 'aegis -mv \!* -v'
	sh$	aemv(){aegis -mv "$@" -v}

	It is an error if the change is	not in the being developed state.
	It is an error if the change is	not assigned to	the current user.
	It is an error if either file is already in the	change.

	The aegis command will exit with a status of 1 on any error.  The
	aegis command will only	exit with a status of 0	if there are no	er-

	See aegis(1) for a list	of environment variables which may affect this
	command.  See aepconf(5) for the project configuration file's
	project_specific field for how to set environment variables for	all
	commands executed by Aegis.

	aecp(1)	copy files into	a change

	aedb(1)	begin development of a change

		undo the rename	files as part of a change

	aenf(1)	add files to be	created	by a change

		remove files to	be created by a	change

	aerm(1)	add files to be	deleted	by a change

		remove files to	be deleted by a	change

		user configuration file	format

	aegis version 4.25.D510
	Copyright (C) 1991, 1992, 1993,	1994, 1995, 1996, 1997,	1998, 1999,
	2000, 2001, 2002, 2003,	2004, 2005, 2006, 2007,	2008, 2009, 2010,
	2011, 2012 Peter Miller

	The aegis program comes	with ABSOLUTELY	NO WARRANTY; for details use
	the 'aegis -VERSion License' command.  This is free software and you
	are welcome to redistribute it under certain conditions; for details
	use the	'aegis -VERSion	License' command.

	Peter Miller   E-Mail:
	/\/\*		  WWW:

Reference Manual		     Aegis		   aegis -MoVe_file(1)


Want to link to this manual page? Use this URL:

home | help