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

FreeBSD Manual Pages

  
 
  

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

NAME
	aegis move file	undo - undo the	rename a file as part of a change

SYNOPSIS
	aegis -MoVe_file_Undo [	option...  ] filename...
	aegis -MoVe_file_Undo -List [ option...	 ]
	aegis -MoVe_file_Undo -Help

DESCRIPTION
	The aegis -MoVe_file_Undo command is used to reverse the effects of
	the aegis -MoVe_file command.  You only	need to	name one half of the
	rename,	the other half will be determined automatically.  You may
	apply this command to whole directories.

	The named files	will be	removed	from the development directory,	and
	removed	from the list of files in the change.

   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-
	mation.

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

   Notification
	The new_file_undo_command and remove_file_undo_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.

WHITEOUT
	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
	being developed	state, the file	is only	"removed" in the development
	directory - 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
	fatal 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.inc: manifest.make.awk
		    ( aegis -l cf -ter ; aegis -l pf -ter ) | \
		    awk	-f manifest.make.awk > manifest.make.inc
		# now include the file manifest
		include	manifest.make.inc
	Note: this would be inefficient	of you did it once per directory, but
	there is nothing stopping you writing numerous assignments into	the
	manifest.make.inc 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
	times.
		/* run when the	change file manifest is	altered	*/
		change_file_command = "rm -f manifest.make.inc";
		/* run when the	project	file manifest is altered */
		project_file_command = "rm -f manifest.make.inc";
	The new	file manifest will thus	be re-built during the next aeb(1)
	command.

   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
	permanently.

   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
	all.

	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.

   Notification
	On successful completion of this command, the notifications usually
	performed by the aermu(1), aenfu(1) and	aentu(1) commands are run, as
	appropriate.  These include the	project_file_command, new_file_undo_-
	command, new_test_undo_command and remove_file_undo_command fields of
	the project config file.  See aepconf(5) for more information.

OPTIONS
	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
		option.

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

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

	-Not_Logging
		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.

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

	-Verbose
		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
		added.

	-Verify_Symbolic_Links
		This option may	be used	to request that	the symbolic links, or
		hard links, or file copies, in the work	area be	updated	to
		reflect	the current state of the baseline.  This is controlled
		by the development_directory_style field of the	project	con-
		figuration file.  Only files which are not involved in the
		change are updated.  See also the "symbolic_links_preference"
		field of aeuconf(5).  This option is the default, if meaning-
		ful for	your configuration.  The name is an historical acci-
		dent, hard links and file copies are included.

	-Assume_Symbolic_Links
		This option may	be used	to request that	no update of baseline
		mirror files take place.  This options is useful when you def-
		initely	know the files'	up-to-date-ness	isn't important	right
		now; incorrect use of this option may have unanticipated build
		side-effects.  See also	the "symbolic_links_preference"	field
		of aeuconf(5).	This option is the default, if not meaningful
		for your configuration.	 The name is an	historical accident,
		hard links and file copies are included.

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

	-No_Wait
		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.

	-WhiteOut
		This option may	be used	to request that	deleted	files be
		replaced by a "whiteout" file in the development directory.
		The idea is that compiling such	a file will result in a	fatal
		error, in order	that all references may	be found.  This	is
		usually	the default.

	-No_WhiteOut
		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
	optional.  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
	"--option=value" convention is also understood.

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

ERRORS
	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 the file is not being	moved by the change.

EXIT STATUS
	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
	errors.

ENVIRONMENT VARIABLES
	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.

SEE ALSO
	aecp(1)	copy files into	a change

	aedb(1)	begin development of a change

	aemv(1)	rename files as	part of	a change

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

	aenfu(1)
		remove files to	be created by a	change

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

	aermu(1)
		remove files to	be deleted by a	change

	aeuconf(5)
		user configuration file	format

COPYRIGHT
	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.

AUTHOR
	Peter Miller   E-Mail:	 pmiller@opensource.org.au
	/\/\*		  WWW:	 http://miller.emu.id.au/pmiller/

Reference Manual		     Aegis	      aegis -MoVe_file_Undo(1)

NAME | SYNOPSIS | DESCRIPTION | WHITEOUT | OPTIONS | RECOMMENDED ALIAS | ERRORS | EXIT STATUS | ENVIRONMENT VARIABLES | SEE ALSO | COPYRIGHT | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=aemvu&sektion=1&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help