tinyurl.com/bbyft -> svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
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. Doing the task well is all about knowing the tools--what they are, when to use them, and how to use them. This section will introduce you to the repository administration tools provided by Subversion, and how to wield them to accomplish tasks such as repository migrations, upgrades, backups and cleanups. An Administrator's Toolkit Subversion provides a handful of utilities useful for creating, inspecting, modifying and repairing your repository. Afterward, we'll briefly examine some of the utilities included in the Berkeley DB distribution that provide functionality specific 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 revisions and transactions in a repository. No part of this program attempts to change the repository--it's a "read-only" tool. svnlook is typically used by the repository hooks for reporting the changes that are about to be committed (in the case of the pre-commit hook) or that were just committed (in the case of the post-commit hook) to the repository. A repository 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 revision 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 transaction, respectively, to examine. Note that while revision numbers appear as natural numbers, transaction names are alphanumeric strings. Keep in mind that the filesystem only allows browsing of uncommitted transactions (transactions that have not resulted in a new revision). Most repositories will have no such transactions, because transactions are usually either committed (which disqualifies them from viewing) or aborted and removed. 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 youngest 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 youngest subcommand, which takes no options, and simply prints out the HEAD revision number. Take 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 displayed using a textual representation instead of something more obscure (such as the number of nanoseconds since the Tasty Freeze guy drove by). But this output is also machine-parsable--because the log message can contain multiple lines and be unbounded in length, svnlook provides the length of that message before the message itself. This allows scripts and other 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 last bit of data in the stream. Another common use of svnlook is to actually view the contents of a revision or transaction tree. The svnlook tree command displays the directories 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 paths (which is generally of more use to developers than to users). svnlook can perform a variety of other queries, displaying subsets of bits of information we've mentioned previously, reporting which paths were modified in a given revision or transaction, showing textual and property differences made to files and directories, and so on. The following is a brief description of the current list of subcommands accepted by svnlook, 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. Besides providing the ability to create Subversion repositories, this program allows you to perform several maintenance operations on those repositories.
the section called "Repository Creation and Configuration"). Most of the others we will 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 files--those 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. lslocks List and describe any locks that exist in the repository. 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, attempting manual tweaks is unwise, if not quite difficult. And once data has been stored in your repository, Subversion generally doesn't provide an easy way to remove that data.
You might need to strip out all instances of a file that was accidentally added to the repository (and shouldn't be there for whatever reason). Or, perhaps you have multiple projects sharing a single repository, and you decide to split them up into their own repositories. To accomplish tasks like this, administrators need a more manageable and malleable representation of the data in their repositories--the Subversion repository dump format. 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 aspec...
|
http://csua.com/feed/