Version Control with Subversion - Login

Repository Administrationsions will contain only the original datestamp, and a generated log message that indicatesthat this revision was emptied by svndumpfilter.While svndumpfilter can be very useful and a huge timesaver, there are unfortunately acouple of gotchas. First, this utility is overly sensitive to path semantics. Pay attention towhether paths in your dump file are specified with or without leading slashes. You'll want tolook at the Node-path and Node-copyfrom-path headers.…Node-path: spreadsheet/Makefile…If the paths have leading slashes, you should include leading slashes in the paths you passto svndumpfilter include and svndumpfilter exclude (and if they don't, you shouldn't).Further, if your dump file has an inconsistent usage of leading slashes for some reason, 11you should probably normalize those paths so that they all have, or all lack, leadingslashes.Also, copied paths can give you some trouble. Subversion supports copy operations in therepository, where a new path is created by copying some already existing path. It is possiblethat at some point in the lifetime of your repository, you might have copied a file or directoryfrom some location that svndumpfilter is excluding, to a location that it is including.To make the dump data self-sufficient, svndumpfilter needs to still show the addition ofthe new path—including the contents of any files created by the copy—and not representthat addition as a copy from a source that won't exist in your filtered dump data stream. Butbecause the Subversion repository dump format shows only what was changed in each revision,the contents of the copy source might not be readily available. If you suspect thatyou have any copies of this sort in your repository, you might want to rethink your set of included/excludedpaths, perhaps including the paths that served as sources of your troublesomecopy operations, too.Finally, svndumpfilter takes path filtering quite literally. If you are trying to copy the historyof a project rooted at trunk/my-project and move it into a repository of its own, youwould, of course, use the svndumpfilter include command to keep all the changes in andunder trunk/my-project. But the resultant dump file makes no assumptions about therepository into which you plan to load this data. Specifically, the dump data might beginwith the revision that added the trunk/my-project directory, but it will not contain directivesthat would create the trunk directory itself (because trunk doesn't match the includefilter). You'll need to make sure that any directories that the new dump stream expectsto exist actually do exist in the target repository before trying to load the stream intothat repository.Repository ReplicationThere are several scenarios in which it is quite handy to have a Subversion repositorywhose version history is exactly the same as some other repository's. Perhaps the mostobvious one is the maintenance of a simple backup repository, used when the primary repositoryhas become inaccessible due to a hardware failure, network outage, or other suchannoyance. Other scenarios include deploying mirror repositories to distribute heavy Subversionload across multiple servers, use as a soft-upgrade mechanism, and so on.As of version 1.4, Subversion provides a program for managing scenarios such asthese—svnsync. This works by essentially asking the Subversion server to “replay” revisions,one at a time. It then uses that revision information to mimic a commit of the same toanother repository. Neither repository needs to be locally accessible to the machine onwhich svnsync is running—its parameters are repository URLs, and it does all its workthrough Subversion's Repository Access (RA) interfaces. All it requires is read access to11 While svnadmin dump has a consistent leading slash policy (to not include them), other programs that generatedump data might not be so consistent.146