ViewVC 1.1.0 Release Notes

Introduction

ViewVC 1.1.0 is the superset of all previous ViewVC releases.

Compatibility

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.

Features and Fixes

Extensible path-based authorization w/ Subversion authz support

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.

Subversion versioned properties display

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.

Unified markup and annotation views

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.

Unified, hassle-free Pygments-based syntax highlighting

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.

Better MIME detection and handling

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.

Support for full content diffs

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

Support for per-root configuration overrides

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.

Optional email address obfuscation/mangling

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

Pagination improvements

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.