11.07.2015 Views

Version Control with Subversion - Login

Version Control with Subversion - Login

Version Control with Subversion - Login

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Repository Administration-bypass-hooks option to the svnadmin setlog command.Managing Disk SpaceRemember, though, that by bypassing the hooks, you are likely avoiding suchthings as email notifications of property changes, backup systems that trackunversioned property changes, and so on. In other words, be very carefulabout what you are changing, and how you change it.While the cost of storage has dropped incredibly in the past few years, disk usage is still avalid concern for administrators seeking to version large amounts of data. Every bit of versionhistory information stored in the live repository needs to be backed up elsewhere, perhapsmultiple times as part of rotating backup schedules. It is useful to know what piecesof <strong>Subversion</strong>'s repository data need to remain on the live site, which need to be backedup, and which can be safely removed.How <strong>Subversion</strong> saves disk spaceTo keep the repository small, <strong>Subversion</strong> uses deltification (or deltified storage) <strong>with</strong>in therepository itself. Deltification involves encoding the representation of a chunk of data as acollection of differences against some other chunk of data. If the two pieces of data arevery similar, this deltification results in storage savings for the deltified chunk—rather thantaking up space equal to the size of the original data, it takes up only enough space to say,“I look just like this other piece of data over here, except for the following couple ofchanges.” The result is that most of the repository data that tends to be bulky—namely, thecontents of versioned files—is stored at a much smaller size than the original full-text representationof that data. And for repositories created <strong>with</strong> <strong>Subversion</strong> 1.4 or later, thespace savings are even better—now those full-text representations of file contents arethemselves compressed.Because all of the data that is subject to deltification in a BDB-backed repositoryis stored in a single Berkeley DB database file, reducing the size of thestored values will not immediately reduce the size of the database file itself.Berkeley DB will, however, keep internal records of unused areas of the databasefile and consume those areas first before growing the size of the databasefile. So while deltification doesn't produce immediate space savings, itcan drastically slow future growth of the database.Removing dead transactionsThough they are uncommon, there are circumstances in which a <strong>Subversion</strong> commit processmight fail, leaving behind in the repository the remnants of the revision-to-be thatwasn't—an uncommitted transaction and all the file and directory changes associated <strong>with</strong>it. This could happen for several reasons: perhaps the client operation was inelegantly terminatedby the user, or a network failure occurred in the middle of an operation. Regardlessof the reason, dead transactions can happen. They don't do any real harm, other thanconsuming disk space. A fastidious administrator may nonetheless wish to remove them.You can use the svnadmin lstxns command to list the names of the currently outstandingtransactions:$ svnadmin lstxns myrepos193a1a45$136

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!