svnbook.red-bean.com/en/1.1/ch05s03.html#svn-ch-5-sect-3.6
Next Repository Maintenance Maintaining a Subversion repository can be a daunting task, mostly due to the complexities inherent in systems which have a database backend. Doi ng the task well is all about knowing the toolswhat they are, when to u se them, and how to use them. This section will introduce you to the rep ository administration tools provided by Subversion, and how to wield th em to accomplish tasks such as repository migrations, upgrades, backups and cleanups. An Administrator's Toolkit Subversion provides a handful of utilities useful for creating, inspectin g, modifying and repairing your repository. Afterward, we'll briefly examine some of the utiliti es included in the Berkeley DB distribution that provide functionality s pecific to your repository's database backend not otherwise provided by Subversion's own tools. svnlook svnlook is a tool provided by Subversion for examining the various revisi ons and transactions in a repository. No part of this program attempts t o change the repositoryit's a read-only tool. svnlook is typically us ed by the repository hooks for reporting the changes that are about to b e committed (in the case of the pre-commit hook) or that were just commi tted (in the case of the post-commit hook) to the repository. A reposito ry administrator may use this tool for diagnostic purposes.
Note: any subcommand which takes the '--revision' and '--transaction' options will, if invoked without one of those options, act on the repository's youngest revision. Type "svnlook help <subcommand>" for help on a specific subcommand. Nearly every one of svnlook's subcommands can operate on either a revisio n or a transaction tree, printing information about the tree itself, or how it differs from the previous revision of the repository. You use the --revision and --transaction options to specify which revision or trans action, respectively, to examine. Note that while revision numbers appea r as natural numbers, transaction names are alphanumeric strings. Keep i n mind that the filesystem only allows browsing of uncommitted transacti ons (transactions that have not resulted in a new revision). Most reposi tories will have no such transactions, because transactions are usually either committed (which disqualifies them from viewing) or aborted and r emoved. In the absence of both the --revision and --transaction options, svnlook will examine the youngest (or HEAD) revision in the repository. So the following two commands do exactly the same thing when 19 is the younges t revision in the repository located at /path/to/repos: $ svnlook info /path/to/repos $ svnlook info /path/to/repos --revision 19 The only exception to these rules about subcommands is the svnlook younge st subcommand, which takes no options, and simply prints out the HEAD re vision number. T ake as an example the output of the info subcommand: $ svnlook info /path/to/repos sally 2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002) 27 Added the usual Greek tree. The output of the info subcommand is defined as: 1 The author, followed by a newline. This output is human-readable, meaning items like the datestamp are displ ayed using a textual representation instead of something more obscure (s uch as the number of nanoseconds since the Tasty Freeze guy drove by). B ut this output is also machine-parsablebecause the log message can cont ain multiple lines and be unbounded in length, svnlook provides the leng th of that message before the message itself. This allows scripts and ot her wrappers around this command to make intelligent decisions about the log message, such as how much memory to allocate for the message, or at least how many bytes to skip in the event that this output is not the l ast bit of data in the stream. Another common use of svnlook is to actually view the contents of a revis ion or transaction tree. The svnlook tree command displays the directori es and files in the requested tree. If you supply the --show-ids option, it will also show the filesystem node revision IDs for each of those pa ths (which is generally of more use to developers than to users). svnlook can perform a variety of other queries, displaying subsets of bit s of information we've mentioned previously, reporting which paths were modified in a given revision or transaction, showing textual and propert y differences made to files and directories, and so on. The following is a brief description of the current list of subcommands accepted by svnl ook, and the output of those subcommands: author Print the tree's author. changed List all files and directories that changed in the tree. dirs-changed List the directories in the tree that were themselves changed, or whose file children were changed. history Display interesting points in the history of a versioned path (places where modifications or copies occurred). info Print the tree's author, datestamp, log message character count, and log message. propget Print the value of a property on a path in the tree. proplist Print the names and values of properties set on paths in the tree. tree Print the tree listing, optionally revealing the filesystem node revision IDs associated with each path. uuid Print the repository's UUID Universal Unique IDentifier. svnadmin The svnadmin program is the repository administrator's best friend. Besid es providing the ability to create Subversion repositories, this program allows you to perform several maintenance operations on those repositor ies.
the section called Repository Creation and Configuration). Most of the others we w ill cover in more detail later in this chapter. For now, let's just take a quick glance at what each of the available subcommands offers. deltify Run over a specified revision range, performing predecessor deltification on the paths changed in those revisions. If no revisions are specified, this command will simply deltify the HEAD revision. dump Dump the contents of the repository, bounded by a given set of revisions, using a portable dump format. You can run this command at any time and make a safe copy of the repository, regardless if other processes are using the repository. This list includes all log filesthose still in use by Subversion, as well as those no longer in use. You may safely remove these log files from the repository layout, possibly archiving them for use in the event that you ever need to perform a catastrophic recovery of the repository. load Load a set of revisions into a repository from a stream of data that uses the same portable dump format generated by the dump subcommand. lstxns List the names of uncommitted Subversion transactions that currently exist in the repository. recover Perform recovery steps on a repository that is in need of such, generally after a fatal error has occurred that prevented a process from cleanly shutting down its communication with the repository. rmtxns Cleanly remove Subversion transactions from the repository (conveniently fed by output from the lstxns subcommand). setlog Replace the current value of the svn:log (commit log message) property on a given revision in the repository with a new value. This includes, among other things, checksum comparisons of the versioned data stored in the repository. svndumpfilter Since Subversion stores everything in an opaque database system, attempti ng manual tweaks is unwise, if not quite difficult. And once data has be en stored in your repository, Subversion generally doesn't provide an ea sy way to remove that data.
You m ight need to strip out all instances of a file that was accidentally add ed to the repository (and shouldn't be there for whatever reason). Or, p erhaps you have multiple projects sharing a single repository, and you d ecide to split them up into their own repositories. To accomplish tasks like this, administrators need a more manageable and malleable represent ation of the data in their repositoriesthe Subversion repository dump f ormat. The Subversion repository dump format is a human-readable representation of the changes that you've made to your versioned data over time.
The great thing about the human-readability aspect o f the dump format is that, if y...
|
http://csua.com/feed/