ViewVC 1.1.0 is the superset of all previous ViewVC releases.
Each ViewVC release strives to maintain URL stability with previous releases, and 1.1.0 is no exception. All URLs considered valid for previous ViewVC releases should continue to work correctly in this release, though possibly only via the use of HTTP redirects (generated by ViewVC itself).
The commits database functionality has changed in ViewVC 1.1.0 in
way that breaks compatibility with prior ViewVC releases, but only
for new database instantiations. ViewVC 1.1.0 will continue to
understand (for both read and write operations) the previous
schema, so you are not required to rebuild your commits database
for ViewVC 1.1.0 compatibility. By default, new commits databases
created using the 1.1.0 version of the make-database
script will use a new database schema that is unreadable by
previous ViewVC versions. However, if you need a database which
can co-exist with a previous ViewVC version, you can use
the --version=1.0
option
to make-database
.
The ViewVC configuration files and template language have changed
dramatically. See the file docs/upgrading-howto.html
in the release for information on porting existing versions of
those items for use with ViewVC 1.1.0.
In a nutshell, ViewVC is now able to do path-based authorization. ViewVC 1.0 has a configuration option for naming 'forbidden' modules, but it is really limited — it basically just makes a universal decision about which top-level directories in every hosted repository should be hidden by ViewVC. People want more, and specifically requested that ViewVC learn how to honor Subversion's authz files and semantics. So, along with some other types of authorization approaches, that's what ViewVC 1.1 can now do. If you are using mod_authz_svn with Apache today, or svnserve's built-in authorization support, then you can now point ViewVC to the same authz configuration file and have it honor the access rules you've defined for your repositories.
Note that ViewVC does not handle authentication, though. You'll need to configure your web server to demand login credentials from users, which the web server itself can then hand off to ViewVC for application against the authorization rules you've defined.
WARNING: The root listing view does not consult the
authorization subsystem when deciding what roots to display to a
given user. If you need to protect your root names, consider
disabling it by removing roots
from the set of views
listed in the allowed_views
configuration option.
UPDATE: This was fixed in ViewVC 1.1.3.
WARNING: Support for path-based authorization is incomplete in the experimental version control backend modules, including the one that permits display of remote Subversion repositories. UPDATE: This was fixed in ViewVC 1.1.15.
ViewVC 1.1 displays the properties that Subversion lets you store
on files and directories
(svn:mime-type
, svn:mergeinfo
,
svn:ignore
, etc.). Directory properties are shown by
default at the bottom of that directory's entry listing. File
properties are displayed at the bottom of that file's
markup/annotate view.
The "markup" and "annotate" views in ViewVC now have a unified look and feel (driven by a single EZT template). Both views support syntax highlighting and Subversion file property display.
ViewVC 1.0 does syntax highlighting by working with GNU enscript, or highlight, or php, or py2html — all these external tools just to accomplish a single task. But they all do things in slightly different ways. And if you configure them wrongly, you get strange errors. Pygments (which is also used by Trac for syntax highlighting) is a Python package that requires no configuration, is easier to use inside ViewVC, and so on. So ViewVC 1.1 drops support for all those various old integrations, and just uses Pygments for everything now. This change was about developer and administrator sanity. There will be complaints, to be sure, about how various color schemes differ and what file types now are and aren't understood by the syntax highlighting engine, but this change should vastly simplify the discussions of such things.
ViewVC typically consults a MIME types file to determine what kind
of file a given document is, based on its filename extension
(.jpg
= image/jpeg
, …). But
Subversion lets you dictate a file's MIME type using
the svn:mime-type
property. ViewVC now recognizes and
honors that property as the preferred source of a file's MIME type.
This can be disabled in the configuration, though, which might be
desirable if many of your Subversion-versioned files carry the
generic application/octet-stream
MIME type that
Subversion uses by default for non-human-readable files.
Also, ViewVC now allows you to specify multiple MIME type mapping files that you'd like it to consult when determine the MIME type of files based on their extensions. This allows administrators to easily define their own custom mappings for ViewVC's benefit without potentially affecting the mappings used by other site services.
ViewVC 1.1 expands the previously existing options of "colored diff" and "long colored diff" with a new "full colored diff", which shows the full contents of the changed file (instead of only the 3 or 15 lines of context shown via the older diff display types).
In ViewVC 1.1, you can setup configuration option overrides on a
per-root (per-repository) basis (if you need/care to do so). See
the comments in the viewvc.conf.dist
file for more on
how to do this.
ViewVC can, when displaying revision metadata, munge strings that look like email addresses to protect them from screen-scraping spammers. For example, a log message that says, "Patch by: cmpilato@red-bean.com" can optionally be displayed by ViewVC using HTML entity encoding for the characters (a trick that causes no visible change to the output, but that might confuse unsophisticated spam bot crawlers) or as "Patch by: cmpilato@..." (which isn't a complete email address at all, but might be enough information for the human reading the log message to know who to blame for the patch).
The way that ViewVC splits directory and log views across pages has been reworked. The old way was "Fetch all the information you can find, then display only one page's worth." The new way is "Fetch only what you need to display the page requested, plus a little bit of border information." This provides a large performance enhancement for the default sort orderings.