aesvt -CHeck_In -HIstory file -File input‐file [ -e edit ] [ name=value ...]
aesvt -List -HIstory file
aesvt -Query -HIstory file
It is able to cope with binary files, and with reasonable efficiently if they are not too large.
It has good end‐to‐end properties because it keeps a checksum for each file version, and a checksum for the whole history file.
There is no provision for keyword substitution of any kind. A check‐out will exactly reproduce the input file. A check‐in will never alter the input file.
This option may be used to specify the compression to be used. They are listed on order of compression effeciency.
More compression algorithms may be added in the future.
All other options will produce a diagnostic error.
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 interpreted 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 aesvt are long, this means ignoring the extra leading '-'. The “--option=value” convention is also understood.
This combination of header and data has good end‐to‐end behaviour, because there is a checksum to validate the file data against. Bad blocks in the data will be detected then next time a check‐in or check‐out is attempted.
The format of the history file consists of one or more file versions with the above layout, joined head‐to‐tail with no separators or boundary indicators of any kind. The versions are in descending order, from most recent (greatest edit number) to least recent (version number one). To determine where one version stops and the next version starts, use the Content‐Length field in the header. The entire history file is then compressed using the bunzip2 algorithm (via libbz2). There is no diff or delta of any kind in the history file.
The advantage of compressing the file is that there is usually a very high redundancy between file versions. For example, if two identical versions are checked in (not necessarily sequentially) the second copy will compress to only a few bytes. Unlike diff(1) style deltas, this also copes very will with moving blocks of data within the file. The use of bunzip2 formatting means there is also a checksum for the whole history file, which allows you to detect bad blocks in the header portions; it also means there is a simple way to extract the data from a history file even without the aesvt program, or for testing, or because you are curious.
You can actually choose from a number of compression algorithms, including GNU Zip and bunzip2, via the -compression‐algorithm option. More copmpresison algoritthms may be added in the future. The best available comression is used, because this results in the most compact history files. Future versions will always be able to access the compression used by earlier versions.
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 aesvt program comes with ABSOLUTELY NO WARRANTY; for details
use the 'aesvt -VERSion License' command. This is free software and
you are welcome to redistribute it under certain conditions; for details use
the 'aesvt -VERSion License' command.