China
Korea
Japan
Subversion® projects, repositories, servers, and working copies come in all sizes and shapes; no two are alike. Subversion was designed to support this diversity. Still, there are edges to this world, places you probably shouldn't go, and mistakes you probably don't want to make. There are cautions and guidelines in The Subversion Book and the Subversion Project, but it seemed to us it might be useful to collect together some community wisdom here.
Here are some rules, or guidelines, or best practices, for keeping your Subversion project healthy. These rules are not absolutes. No one's warranty is void for crossing these lines. But these are, by design and experience, effective ways to keep things running smoothly.
Rule Number 0: Proceed with caution beyond these limits.
If you find you have some reason to want to break any of these rules, proceed with caution. You may be alright, you may have trouble. Whether it works or not may depend on factors outside your control or visibility, like who else is doing what at the same time. Then again, you may be able to find ways to stretch the limits significantly, reliably. But expect it to be tricky; expect it to be worth occasional review.
Rule Number 1: Use the working copy. That's what it's for.
Subversion was designed for a use model where checkout is fairly rare (say, once a week), and update is fairly common (say, several times a day). Lots of stuff is stored in the working copy (during checkout) with no other purpose than to make update fast and cheap. Subversion also takes great care to ensure that "update" gets you the right results--managing directories as well as files, removing things that should go away, not being fooled by timestamps, carefully tracking and reporting conflicts, and so on. Whenever you have the choice, choose update over checkout.
Rule Number 2: Look like code.
The statistics of your working copy ought to be sort of similar to what you might find in a source code tree.
- Individual files of 10's or 100's of kilobytes are fine; megabytes and terabytes are going to surprise the system.
- Likewise, individual directories containing 10's or 100's of files and subdirectories are fine; if you get to thousands and tens of thousands, you may not be so happy.
- Directory paths need to fit within the rules of your local (client) platform; in the most limiting case, if you use Windows clients, you may have to keep all paths, from drive letter to the end of the file name, to well below 256 characters ("below," because Subversion creates a directory below each of yours, and directories and files below that, and this all has to fit into the platform limit).
- On the other hand, Subversion's not at all concerned about large numbers of files and directories, if they're well spread out throughout the repository: a thousand or ten thousand or a million files will take longer to process than ten, of course, but only more or less linearly so, not explosively.
Rule Number 3: Go easy on Subversion properties.
The Subversion design expects properties (either versioned or revision) to contain things like author name, a date stamp, or a dozen or so lines of commit-log text. The design does not anticipate megabyte properties. Likewise, keep the total number of properties on any one file, directory, or revision to a few dozen or less, not hundreds or thousands.
Rule Number 4: Robots cost more than you think.
A robot (such as a continuous integration build 'bot) will typically only perform the same individual actions as a developer, which sounds un-scary. But if a developer does something like checkout once a week, and a build 'bot does it once an hour, then the 'bot is actually the equivalent of several hundred developers--no disaster, but definitely more than "one." If you turn your 'bot up to once a minute, it's 10,080 developers, and that's a notable load to add to anyone's system. 'Bots are the most important place to consider the impact of your workflow, and apply all these guidelines to reduce the load.
