Version Control with Subversion - Login

Repository AdministrationBy default, the dump file will be quite large—much larger than the repository itself. That'sbecause by default every version of every file is expressed as a full text in the dump file.This is the fastest and simplest behavior, and it's nice if you're piping the dump data directlyinto some other process (such as a compression program, filtering program, or loadingprocess). But if you're creating a dump file for longer-term storage, you'll likely want tosave disk space by using the --deltas option. With this option, successive revisions offiles will be output as compressed, binary differences—just as file revisions are stored in arepository. This option is slower, but it results in a dump file much closer in size to the originalrepository.We mentioned previously that svnadmin dump outputs a range of revisions. Use the --revision (-r) option to specify a single revision, or a range of revisions, to dump. If youomit this option, all the existing repository revisions will be dumped.$ svnadmin dump myrepos -r 23 > rev-23.dumpfile$ svnadmin dump myrepos -r 100:200 > revs-100-200.dumpfileAs Subversion dumps each new revision, it outputs only enough information to allow a futureloader to re-create that revision based on the previous one. In other words, for any givenrevision in the dump file, only the items that were changed in that revision will appear inthe dump. The only exception to this rule is the first revision that is dumped with the currentsvnadmin dump command.By default, Subversion will not express the first dumped revision as merely differences tobe applied to the previous revision. For one thing, there is no previous revision in the dumpfile! And second, Subversion cannot know the state of the repository into which the dumpdata will be loaded (if it ever is). To ensure that the output of each execution of svnadmindump is self-sufficient, the first dumped revision is, by default, a full representation ofevery directory, file, and property in that revision of the repository.However, you can change this default behavior. If you add the --incremental optionwhen you dump your repository, svnadmin will compare the first dumped revision againstthe previous revision in the repository—the same way it treats every other revision thatgets dumped. It will then output the first revision exactly as it does the rest of the revisionsin the dump range—mentioning only the changes that occurred in that revision. The benefitof this is that you can create several small dump files that can be loaded in succession, insteadof one large one, like so:$ svnadmin dump myrepos -r 0:1000 > dumpfile1$ svnadmin dump myrepos -r 1001:2000 --incremental > dumpfile2$ svnadmin dump myrepos -r 2001:3000 --incremental > dumpfile3These dump files could be loaded into a new repository with the following command sequence:$ svnadmin load newrepos < dumpfile1$ svnadmin load newrepos < dumpfile2$ svnadmin load newrepos < dumpfile3Another neat trick you can perform with this --incremental option involves appending toan existing dump file a new range of dumped revisions. For example, you might have apost-commit hook that simply appends the repository dump of the single revision thattriggered the hook. Or you might have a script that runs nightly to append dump file datafor all the revisions that were added to the repository since the last time the script ran.Used like this, svnadmin dump can be one way to back up changes to your repositoryover time in case of a system crash or some other catastrophic event.142