Version Control with Subversion - Login

Repository AdministrationThe dump format can also be used to merge the contents of several different repositoriesinto a single repository. By using the --parent-dir option of svnadmin load, you canspecify a new virtual root directory for the load process. That means if you have dump filesfor three repositories—say calc-dumpfile, cal-dumpfile, and ss-dumpfile—youcan first create a new repository to hold them all:$ svnadmin create /var/svn/projects$Then, make new directories in the repository that will encapsulate the contents of each ofthe three previous repositories:$ svn mkdir -m "Initial project roots" \file:///var/svn/projects/calc \file:///var/svn/projects/calendar \file:///var/svn/projects/spreadsheetCommitted revision 1.$Lastly, load the individual dump files into their respective locations in the new repository:$ svnadmin load /var/svn/projects --parent-dir calc < calc-dumpfile…$ svnadmin load /var/svn/projects --parent-dir calendar < cal-dumpfile…$ svnadmin load /var/svn/projects --parent-dir spreadsheet < ss-dumpfile…$We'll mention one final way to use the Subversion repository dump format—conversionfrom a different storage mechanism or version control system altogether. Because thedump file format is, for the most part, human-readable, it should be relatively easy to describegeneric sets of changes—each of which should be treated as a new revision—usingthis file format. In fact, the cvs2svn utility (see the section called “Converting a Repositoryfrom CVS to Subversion”) uses the dump format to represent the contents of a CVS repositoryso that those contents can be copied into a Subversion repository.Filtering Repository HistorySince Subversion stores your versioned history using, at the very least, binary differencingalgorithms and data compression (optionally in a completely opaque database system), attemptingmanual tweaks is unwise if not quite difficult, and at any rate strongly discouraged.And once data has been stored in your repository, Subversion generally doesn'tprovide an easy way to remove that data. 9 But inevitably, there will be times when youwould like to manipulate the history of your repository. You might need to strip out all instancesof a file that was accidentally added to the repository (and shouldn't be there forwhatever reason). 10 Or, perhaps you have multiple projects sharing a single repository,and you decide to split them up into their own repositories. To accomplish tasks such asthese, administrators need a more manageable and malleable representation of the data intheir repositories—the Subversion repository dump format.As we described earlier in the section called “Migrating Repository Data Elsewhere”, theSubversion repository dump format is a human-readable representation of the changes9 That's rather the reason you use version control at all, right?10 Conscious, cautious removal of certain bits of versioned data is actually supported by real use cases. That'swhy an “obliterate” feature has been one of the most highly requested Subversion features, and one which theSubversion developers hope to soon provide.143