Version 2.1.24 (20031208)
=========================
This version adds new features and slightly changes the format
of some configuration files. A most notable format change is the
change of the file with the internal contest server state. This
file is generated by the `serve' program and is used by the
`master', `judge', and `team' CGI-programs. This version of
these CGI-programs cannot read the server status file in the old
format, which result in fatal startup errors of the
CGI-programs. To eliminate the fatal startup error just start
the `serve' program manually in this contest directory once. The
`serve' program will regenerate the state file, and then all the
CGI-program will start normally. After the state file is
regenerated, the `serve' program may be stopped. The contest may
then be put under the super-serve's control, and the
`super-serve' program will start the `serve' program
automatically on demand.

All unused and obsoleted files are removed from the ejudge's
source archive. As a result the size of the archive is
noticeable decreased.

If no bugs are found in this release, the next release (which
will be identical or nearly identical to the current release)
will be numbered 2.2.0, so a new stable branch of the `ejudge'
system will be started. The 2.1 branch will be terminated. All
the support work will go to 2.2 branch, and all the new
development will go to the future development branch 2.3.

The `contest.xml' configuration file
------------------------------------
Support for <observer_access> XML element is completely
removed. This XML element was introduced for the `observer'
CGI-program, which was not implemented. The planed functionality
of the `observer' program is a restricted privileged user
interface (more restricted, that of `judge' CGI-program), but
this can be achieved by properly tuning capability bits.
Also the `OBSERVER_LOGIN' capability bit is removed.

A new capability bit `SUBMIT_RUNS' is introduced. If some user
has this capability set, this used is allowed to submit a run
using `master' or `judge' CGI-programs. Runs submitted from
privileged programs differ from the runs submitted by ordinary
users (see below). In order to be able to use `master' or
`judge' program the user must have the corresponding capability
bit (`MASTER_LOGIN' or `JUDGE_LOGIN') set.

serve
-----
The structure of the archive of submits and testing protocols is
optimized. Instead of keeping all the archive files in a single
directory (for example, all the testing protocols was located in
the `var/archive/reports' directory of the contest directory),
the archive files are structured in a directory hierarchy, so
that a directory on each nesting level contains no more, than 32
entries (without `.' and `..'). The maximal number of entries in
the archive is limited by approx. 1 million, thus to store up to
1 million files the nesting level of 3 is sufficient. For
example, the testing protocol for the submit 1905 will be stored
in the file `var/archive/reports/0/1/R/001905'.

Such optimization allows significant increase of access speed
for filesystems, which keep directory entries unordered (for
example ext2/ext3). To disable the new hierarchical form of
archive set the global configuration variable
`use_dir_hierarchy' to 0 with the following line:
use_dir_hierarchy = 0
The hiarchical directory structure of archive directories is
enabled by default.

The old and the new form of storing the archive files are
backward compatible. The new (current) version of the ejudge
system will correctly find archive entries created by the
previous versions. However, if the support for hiarchical files
storage is enabled, all new files will be stored in the
hiarchical directory structure and thus will be unavailable for
the ejudge system of the previous versions.

All the archive entries, which size exceed some limit (4KiB by
default) are compressed using the gzip algorithm. Such entries
are stored in the file with `.gz' suffix to distinguish them
from uncompressed files. The minimal size of archive entries
that need to be compressed may be tuned with `min_gzip_size'
global configuration variable of the `serve.cfg' configuration
file. The default size of 4 KiB (4096 bytes) equals to the
allocation unit size of the contemporary versions of ext2/ext3
file systems on ia32 architecture (and equals to the size of
virtual memory page). Compression for files of smaller size is
pointless, because compression takes processor time and do not
result in decrease of used disk space.

In order to completely disable compression of archive entries
set the `use_gzip' global configuration variable of the
`serve.cfg' configuration file to 0 with the following line:
use_gzip = 0

A new field `variant' to store the problem variant is added to
the run database. By default and for compatibility the variant
is equal to 0, i. e. the variant from the variant map file (set
by the `variant_map_file' global configuration variable) is
used. The variant may be changed explicitly by the contest
administrator, and a user with sufficient privilege level may
submit a run with explicitly specified variant of the problem.

A new field `is_hidden' is added to the run database to indicate
the special status of a run. The "hidden" runs are tested as
usually, but are now shown in the public run log, do not
influence score of the team. The "hidden" runs also may not be
exported to XML. See below a more detailed description of hidden
runs and their usage.

serve,master,judge
------------------
A privileged user may submit a run using `master' or `judge'
CGI-program, if the user has `SUBMIT_RUNS' capability bit set.
The corresponding form is added to HTML pages generated by the
`master' and `judge' CGI-programs. A run submitted from `master'
or `judge' is added to the run database with "hidden" flag set.
It means, that such run is tested as usually, but the run is not
counted when the current standings are calculated. The hidden
run is not shown in the public runlog. The hidden run is never
exported to XML.

A privileged user may submit a run for any problem (even for
problem with expired deadline), may specify any variant of the
problem (if the problem has variants), may use any programming
language (even disabled one). Submit time is not checked for
privileged runs, i. e. they may be sent before the start of the
contest or after the end of the contest. User quota are also not
checked for privileged runs.

serve,master
------------
Added support for editing of the new run database fields
`variant' and `is_hidden'.

judge
-----
Fixed a bug of invalid formatting of submission table for
VIRTUAL START and VIRTUAL END event and for EMPTY records.

run
---
Zero test score is allowed. In the previous versions of the
ejudge system test score 0 meant default test score (1). Tests
with zero score are handled correctly. Zero-scored tests are
useful for judging a problem using "accepted"/"not-accepted"
system in the `KIROV' contest score system.

serve,master
------------
Changing of the contest duration is allowed after the end of the
contest (by any reason: explicit "Stop contest" administrator
command and contest duration expiration). To allow changing of
the duration after the end of the contest, the global
configuration variable `enable_continue' of the contest
configuration file `serve.cfg' must be set to non-zero value.
The following line in the configuration file will do:
enable_continue

The contest administrator is allowed to decrease the contest
duration using the "Change duration" command (in the previous
versions the administrator may only increase the contest
duration). However, if the contest is in progress (already
started), decrease of the contest duration may not cause
immediate stop of the contest due to contest duration
expiration. Such contest duration changes are disallowed and
will cause a user error.

Decrease of duration of unlimited in duration contests is
disallowed. Increase of limited contest duration to unlimited is
also disallowed.

Almost any contest may be continued after stop if the
`enable_continue' global configuration variable is set to
non-zero value. It is possible to continue stopped contest of
limited duration, if the current time is before the time when
the contest whould stop due to contest time expiration. The
contest, which is stopped due to contest time expiration may be
extended in two turns: first the contest duration is extended
with "Change duration" command, and then the contest is
continued using "Continue" command. Note again, that the
`enable_continue' configuration variable must be set to allow
continuation of allready stopped contest.

serve
-----
The 0 value of the global configuration variable
`board_fog_time' means, that the standings are not frozen at
all. In the previous versions it was impossible to turn off
standings freeze (the only way was to set the freeze time 1
minute before the end of the contest).

New global configuration variables `stand_freeze_time' and
`stand_melt_time' are introduced. These variables are aliases
for the `board_fog_time' and `board_unfog_time' configuration
variables respectively. The new variable names better reflect
the variable usage. All names are supported.

serve,master,judge,team
-----------------------
If the standings freeze is enabled for the contest (i. e. the
contest has limited duration and the `board_fog_time' is
positive), the expected standings freeze time is shown to users
in the server state section of the generated html pages.

team
----
"Client time:" line is removed from the server state section of
the team-generated HTML page, because the name of the line does
not match its meaning. "Client time" always means the time when
the `team', `judge', or `master' CGI-program is invoked to
process the client's request.

serve,team
----------
A new global configuration variable `team_enable_ce_view' is
introduced in the contest configuration file `serve.cfg'. If
this configuration variable is set to non-zero value, the
compilation log is available to participants in case of compile
errors. The compilation log is available even if testing
protocols are not available to participants (i. e. if global
configuration variable `team_enable_rep_view' is set to 0).

A new global configuration variable `team_show_judge_report' is
introduced in the contest configuration file `serve.cfg'. If
this configuration variable is set to non-zero value, and
testing protocols are available to the participants (i. e. if
global configuration variable `team_enable_rep_view' is set to
non-zero value), the participants view the judge's testing
protocol, not the team's. The judge's testing protocol contains
complete information about testing of a run: input data (tests),
program output, program output to stderr, output of the checker,
etc. By default participants may only view limited (team's)
version of the testing protocol, which only contains the result
of running the program on tests, but not the tests themselves,
not the output of the program. The full protocol showing mode
may be enabled or disabled for each problem individually by
explicit specification of value of `team_show_judge_report'
configuration variable in the problem description.

serve
-----
Bug is fixed, when the `serve' program terminated due to
assertion failed, if no users were registered for a contest.

serve,master
------------
The contest administrator may suspend testing of incoming runs
using the "Suspend testing" command. In the suspended testing
mode all the participant's submits are accepted as usually, but
runs are not queued for compilation and subsequent execution,
but are stored into the run database with "Accepted for testing"
status. The runs will remain in this status until they will be
rejudged by the administrator explicitly or by "Judge suspended
runs" command. The "Suspend testing" command is useful to
decrease the server load at the end of the contest (when submit
stream is usually very intensive), especially, if the contest
server is simultaneously compilation server or testing server
for the contest. When testing is suspended, the "Resume testing"
command is available to the administrator to resume the normal
mode.

The contest administrator may judge all pending runs accepted
when testing was suspended using "Judge suspended runs"
command.

serve,master,judge
------------------
`status' and `curstatus' constructs are available in filter
expressions. These are aliases for `result' and `curresult'.

Version 2.1.23 (20031121)
=========================
A bugfix release. No new features. No new configuration variables.

An unofficial Russian translations of the GNU General Public License
and GNU Lesser General Public License is added to source distribution.

serve, compile, run
-------------------

Configuration file format now supports quotes inside parameters. The
standard syntax of ", ', and \ (see description of test.inf file
format) is supported. For example,
table_head_style = 'h2 style="common"'

serve/master
------------

XML export of standings properly escapes ", & and other problematic
HTML/XML characters.

team
----

Verbose error messages are displayed in case of non-registered users,
banned users.

run
---

Escaped `#' are correctly handled in test.inf file. 

userlist-server
---------------

XML save of userlist database now properly escapes ", & and other
problematic HTML/XML characters.

Hash table lookup is implemented for login lookup and session id lookup.
This drastically (100 times) decreases lookup time.

register
--------

Silent truncating of input fields on "Number" sign is fixed.

libchecker.a
------------

If NEED_TGZ checker flag is on, a checker has access to `dir_in_path'
and `dir_out_path' variables, which contain the path to input directory
(in the tests source directory) and to the working directory of program
being tested respectively. I.e., to open the input directory the
checker should use `opendir(dir_in_path)' function call. To open the
output directory of the program, the checker should use
`opendir(dir_out_path)' function call.

New functions are added to the library:
  checker_read_corr_double,
  checker_read_corr_long_long,
  checker_read_int,
  checker_read_in_long_double,
  checker_read_long_double,
  checker_read_long_long.

