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

FreeBSD Manual Pages


home | help
aegis -clone(1)						       aegis -clone(1)

	aegis clone - make an exact copy of a change

	aegis -CLone [ option...  ] change-number [ change-number ]
	aegis -CLone -Help
	aegis -CLone -VERSion

	The aegis -CLone command is used to create exact replicas of changes.
	This is	of most	use when a change need to be applied to	several	paral-
	lel branches.

	One change number must be supplied.  This is the change	to be repli-
	cated.	If any branch options are given	(see below) the	mandatory
	change number applies to the branch specified.	If no branch is	speci-
	fied, the change applies to the	project	(implicit or explicit).

	If the optional	second change number is	supplied, this is the change
	number to be created to	hold the replica; if it	is not supplied, the
	next available change number will be used.

	If the change to be replicated has been	completed, the appropriate
	file revisions will be extracted from history; otherwise the files
	will be	copied from the	development directory of the change to be
	copied.	 Be warned: if a file in the change which was cloned subse-
	quently	changes, those changes will not	automagically be tracked.  It
	is best	if changes are cloned at a stable time,	such as	one of the
	states after develop end, or even after	integrate pass.

   Development Directory Location
	Please Note: Aegis also	consults the underlying	file system, to	deter-
	mine its notion	of maximum file	size.  Where the file system's maximum
	file size is less than maximum_filename_length,	the filesystem wins.
	This can happen, for example, when you are using the Linux UMSDOS file
	system,	or when	you have an NFS	mounted	an ancient V7 filesystem.
	Setting	maximum_filename_length	to 255 in these	cases does not alter
	the fact that the underlying file systems limits are far smaller (12
	and 14,	respectively).

	If your	development directories	(or your whole project)	is on filesys-
	tems with filename limitations,	or a portion of	the heterogeneous
	builds take place in such an environment, it helps to tell Aegis what
	they are (using	the project config file's fields) so that you don't
	run into the situation where the project builds	on the more permissive
	environments, but fails	with mysterious	errors in the more limited en-

	If your	development directories	are routinely on a Linux UMSDOS
	filesystem, you	would probably be better off setting dos_filename_re-
	quired = true, and also	changing the development_directory_template
	field.	Heterogeneous development with various Windows environments
	may also require this.

	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.

	The notification commands that would be	run by the aecp(1), aedb(1),
	aenf(1), aent(1) and aerm(1) commands are run, as appropriate.	The
	project_file_command is	also run, if set.  See aepconf(5) for more in-

Cloning	and Merging
	When you use aeclone(1)	to clone a change set, and then	integrate one
	of the two change sets,	you will observe that Aegis says that the
	files of the un-integrated change are now out-of-date.

	If you run aem(1) to bring the out-of-date files back up-to-date,
	fmerge(1) and some (but	not) all other merging tools, it signals just
	about everything as a conflict,	even though both alternatives are

	The problem is that two	changes	making identical edits to the same
	place in the same file are a logical conflict, even if not an actual
	conflict, and it takes a human to figure out the difference.  Think of
	a shopping list: the ensuite needs more	soap, and so does the main
	bathroom.  The second "soap" on	the merge of the two shopping lists
	isn't a	duplicate, you really do need two boxes	of soap.  Sometimes
	edits of source	files are the same: sometimes the logical conflict is
	resolved by applying both identical edits, not just one.

	This is	just the fmerge(1) command being more conservative than	RCS's
	merge(1) command.

	The easiest way	to deal	with this common situation it to run an
		aecpu -unchanged
	command	before you run the aem(1) merge	command, and you will have
	less grief.  It's also worth remembering that Aegis stashes the	origi-
	nal file with a	,B suffix (B for backup) so you	can simply
		mv fubar,B fubar
	if you know that all of	the conflicts are logical conflicts.

	The following options are understood:

	-BRanch	number
		This option may	be used	to specify a different branch for the
		origin file, rather than the baseline.	(See also -TRunk op-
		tion.  Please Note: the	-BRanch	option does not	take a project
		name, just the branch number suffix.

		This option may	be used	to specify the grandparent branch (one
		up from	the current branch) for	the origin file, rather	than
		the baseline.  (The -grandparent option	is the same as the
		"-branch .." option.)

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

	-DIRectory path
		This option may	be used	to specify which directory is to be
		used.  It is an	error if the current user does not have	appro-
		priate permissions to create the directory path	given.	This
		must be	an absolute path.

		Caution: If you	are using an automounter do not	use `pwd` to
		make an	absolute path, it usually gives	the wrong answer.

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

	-Output	filename
		This option may	be used	to specify a filename which is to be
		written	with the automatically determined change number.  Use-
		ful for	writing	scripts.

	-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 specify the project trunk for the
		origin file, rather than the baseline.	(See also -BRanch op-
		tion, the -trunk option	is the same as the "-branch -" op-

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

	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.

	It is an error if the current user is not an administrator of the
	project.  (In some cases it is possible	for developers of a project to
	create changes,	see aepattr(5) for more	information.)

	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.

	aenc(1)	Create a new change.

	aeca(1)	modify the attributes of a change

	aena(1)	add a new administrator	to a project

	aepa(1)	modify the attributes of a project

	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 -clone(1)


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

home | help