Version Control with Subversion

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Repository Maintenance

|

95

mation—for example, how likely is it that an operation begun nine months ago is

still active?

In short, transaction cleanup decisions need not be made unwisely. Various sources

of information—including Apache’s error and access logs, the logs of successful Sub-

version commits, and so on—can be employed in the decision-making process.

Finally, an administrator can often simply communicate with a seemingly dead trans-

action’s owner (via email, for example) to verify that the transaction is, in fact, in a

zombie state.

Managing Disk Space

While the cost of storage has dropped incredibly in the past few years, disk usage is

still a valid concern for administrators seeking to version large amounts of data.

Every additional byte consumed by the live repository is a byte that needs to be

backed up offsite, perhaps multiple times as part of rotating backup schedules. Since

the primary storage mechanism of a Subversion repository is a complex database sys-

tem, it is useful to know what pieces of data need to remain on the live site, which

need to be backed up, and which can be safely removed.

Until recently, the largest offender of disk space usage, with respect to Subversion

repositories, was the logfiles to which Berkeley DB performs its pre-writes before

modifying ...