System kontroli wersji (ang. version control system lub revision control system) to zestaw narzędzi do śledzenia i kontrolowania zmian w plikach projektu, w szczególności w kodzie źródłowym, dokumentacji i stronach WWW. Jeśli nigdy nie korzystałeś z kontroli wersji, powinieneś jak najprędzej znaleźć kogoś, kto korzystał, i przekonać go, aby dołączył do projektu. W dzisiejszych czasach każdy spodziewa się, że przynajmniej kod źródłowy projektu znajduje się pod kontrolą wersji, i nie traktuje poważnie projektów, które nie korzystają z niej przynajmniej minimalnie umiejętnie.
Kontrola wersji jest tak uniwersalna, ponieważ pomaga praktycznie w każdym aspekcie projektu: komunikacji między programistami, zarządzaniu wydaniami, śledzeniu błędów, stabilizacji kodu czy eksperymentowaniu, może także służyć do uwierzyteniania i przypisywania zasług poszczególnym programistom. System kontroli wersji stanowi centralny punkt we wszystkich wspomnianych obszarach. Sercem kontroli wersji jest zarządzanie zmianami, pozwalające odróżnić każdą atomową zmianę w plikach projektu, metadane z nią związane (jak data i autor danej zmiany) i przekazać ją do innych użytkowników w sposób, w jaki sobie tego zażyczą. To kanał komunikacyjny, w którym podstawową jednostką informacji jest pojedyncza zmiana.
Ten rozdział nie omawia wszystkich aspektów korzystania z systemu kontroli wersji. To tak rozległy temat, że przy okazji omawiania innych kwestii będziemy do niego wracali jeszcze nie raz w tej książce. Tutaj skupimy się na wybraniu i konfiguracji systemu kontroli wersji w taki sposób, który wspiera współpracę nad rozwojem projektu.
Ta książka nie może nauczyć cię kontroli wersji, jeśli nigdy wcześniej z niej nie korzystałeś. Z drugiej strony trudno byłoby rozmawiać o niej bez wprowadzenia kilku podstawowych pojęć. Te pojęcia są niezależne od konkretnego systemu kontroli wersji, to podstawowe rzeczowniki i przymiotniki gdy współpracujemy w sieci, i będą często stosowane w dalszej części książki. Nawet gdyby nie wymyślono systemów kontroli wersji, problem zarządzania zmianami ciągle by istniał—a więc potrzebujemy języka, pozwalającego mówić o problemie w zwięzły sposób.
Dokonać zmiany w projekcie. Bardziej formalnie, zapisać zmianę w bazie danych systemu kontroli wersji w taki sposób, że może zostać włączona do przyszłych wydań projektu. "Commit" można stosować jako czasownik lub rzeczownik[14], jako rzeczownik to w zasadzie synonim "zmiany". Na przykład: "Właśnie zrobiłem commit poprawki dla błędu powodującego problemy ze stabilnością serwera, zgłaszanego przez użytkowników Mac OS X. Jay, mógłbyś przejrzeć commit i sprawdzić, czy dobrze używam w niej alokatora?"
Krótka wiadomość dołączona do każdego commita, opisująca jego naturę i cel. Komentarze do zmian to jedne z najważniejszych dokumentów każdego projektu, stanowią most pomiędzy bardzo technicznym językiem samego kodu, a bardziej zorientowanym na użytkownika językiem mówiącym o zadaniach, poprawkach błędów i postępie projektu. Dalej w tym rozdziale omówimy sposoby dystrybucji komentarzy zmian do odpowiednich odbiorców. Co więcej, „Codifying Tradition” w Rozdział 6, Communications mówi o tym, jak zachęcić uczestników projektu do pisania zwięzłych i użytecznych komentarzy do zmian.
Aktualizacja to dołączenie zmian dokonanych przez innych do lokalnej kopii projektu, a więc sprawienie, aby kopia stała się aktualna. To bardzo częsta czynność, większość programistów aktualizuje swój kod wiele razy dziennie, aby mieć pewność, że pracują mniej-więcej na tej samej wersji kodu, co pozostali. Co więcej, gdy znajdą błąd, mogą być niemal pewni, że nie został on jeszcze naprawiony. Na przykład: "Hej, zauważyłem, że kod indeksujący zawsze wyrzuca ostatni bajt. Czy to nowy błąd?" "Tak, ale został już naprawiony tydzień temu—zrób aktualizację, powinien zniknąć."
Baza danych, w której zapisywane są zmiany. Niektóre systemy wersji są zcentralizowane: istnieje jedno główne repozytorium, przechowujące wszystkie zmiany. Inne są zdecentralizowane: każdy programista ma swoje własne repozytorium, a zmiany mogą być dowolnie przenoszone pomiędzy repozytoriami. System kontroli wersji śledzi zależności pomiędzy zmianami, i gdy nadejdzie czas wydania, odpowiedni zestaw zmian zostaje zaakceptowany do nowej wersji. Pytanie czy lepsze są systemy zcentralizowane czy rozproszone to jedna z wciąż żywych programistycznych świętych wojen, postaraj się unikać kłótni na ten temat na listach dyskusyjnych projektu.
Proces pobierania kopii projektu z repozytorium. Checkout[15] zazwyczaj tworzy drzewo podkatalogów, nazywane "kopią roboczą" (patrz niżej), w której zmiany mogą być wysyłane do repozytorium (jako commit). W niektórych zdecentralizowanych systemach kontroli wersji każda kopia robocza jest zarazem repozytorium, a zmiany mogą być wypychane z (lub wciągane do) każdego repozytorium, które je zaakceptuje.
Prywatne drzewo katalogów każdego programisty, zawierające kod źródłowy projektu i być może jego stronę WWW, czy inne dokumenty. Kopia robocza zawiera także pewną ilość metadanych, zarządzanych przez system kontroli wersji, określających z jakiego repozytorium pochodzi, jakie "wersje" (patrz niżej) plików są obecne, itd. Na ogół każdy programista ma swoją własną kopię roboczą, w której dokonuje zmian i je testuje, i z której wykonuje commit.
"Wersja" to na ogół konkretne wcielenie danego pliku lub katalogu. Na przykład plik F może być najpierw w wersji 6, następnie ktoś wykonuje commit zmieniający plik F, tworząc wersję 7 pliku F. Niektóre systemy stosują pojęcia "wersja", "zmiana" czy "zbiór zmian" aby opisać zbiór zmian, wysłanych w jednym commicie jako jedna abstrakcyjna operacja.
Niekiedy te pojęcia mają różne znaczenia w poszczególnych systemach kontroli wersji, ale sama idea pozostaje bez zmian: pozwalają one mówić precyzyjnie o pewnych punktach w czasie historii pliku lub zbioru plików (na przykład przed i po poprawce jakiegoś błędu). Na przykład: "Tak, naprawiła to w wersji 10" lub "Naprawiła to w wersji 10 pliku foo.c".
Gdy ktoś mówi o pliku lub grupie plików bez wspominania o konkretnej wersji, na ogół zakłada się, że ma na myśli jego (ich) najnowszą wersję dostępną w repozytorium.
Tekstowa reprezentacja zmiany. Diff wskazuje, które linie uległy zmianie i w jaki sposób, pokazując przy okazji kilka linii kontekstu przed i po. Programista, który zna dany obszar kodu może na ogół przeczytać diff i zrozumieć, na czym polega zmiana, a być może nawet wyłapać błędy.
Określa pewien zbiór plików w ściśle określonych wersjach. Etykiety sa na ogół używane do oznaczania ważnych momentów w życiu projektu. Na przykład etykieta jest na ogół tworzona dla każdego publicznego wydania, tak, aby każdy mógł pobrać bezpośrednio z repozytorium dokładnie te same wersje plików, które zostały wydane. Popularnymi nazwami etykiet są na przykład Release_1_0, Delivery_00456, itd.
Kopia projektu znajdująca się w repozytorium, ale izolowana w taki sposób, że zmiany w gałęzi nie wpływają na resztę projektu, i odwrotnie, do czasu gdy zmiany nie zostaną przez kogoś "scalone" (patrz niżej). Gałęzie bywają także nazywane "liniami rozwoju". Nawet gdy projekt nie posiada wielu gałęzi, mówi się że rozwój odbywa się na "głównej gałęzi", także nazywanej "pniem" (ang. trunk).
Gałęzie dają możliwość odizolowania od siebie różnych linii rozwoju. Na przykład gałąź może powstać na potrzeby eksperymentalnego kodu, który mógłby zdestabilizować główną gałąź. Albo odwrotnie, gałąź może być użyta jako miejsce, w którym nowe wydanie będzie stabilizowane. Podczas procesu wydania normalny rozwój może odbywać się w głównej gałęzi repozytorium, a w tym samym czasie na gałęzi utworzonej dla wydania nie będą akceptowane żadne zmiany oprócz tych, które zostały dozwolone przez zarządzających wydaniem. W ten sposób wydanie nowej wersji nie musi kolidować z normalnym rozwojem. Patrz „Use branches to avoid bottlenecks” dalej w tym rozdziale aby dowiedzieć się więcej o gałęziach.
Przeniesienie zmiany z jednej gałęzi na inną. Chodzi zarówno o scalanie zmian z głównej gałęzi do innej gałęzi, jak i w drugą stronę. To najczęściej stosowane w praktyce rodzaje scaleń—rzadko przenosi się zmiany pomiędzy dwoma gałęziami, z których żadna nie jest główną. Patrz „Singularity of information” oby dowiedzieć się więcej o takich scalaniach.
"Scalanie" ma jeszcze drugie, podobne znaczenie: to zachowanie systemu kontroli wersji gdy stwierdzi, że dwóch użytkowników dokonało zmian w tym samym pliku, które nie zachodzą na siebie. Takie zmiany na ogół nie mają na siebie wpływu, więc u tego użytkownika, który dokona aktualizacji pliku (w którym sam dokonał zmian), zmiany innych zostaną automatycznie scalone. To bardzo częsta sytuacja, szczególnie w projektach, w których wiele osób pracuje nad tym samym kodem. Gdy dwie różne zmiany zachodzą na siebie, pojawia się "konflikt" (patrz niżej).
Konflikt zachodzi, gdy dwie osoby próbują dokonać zmian dokładnie w tym samym miejscu kodu. Wszystkie systemy kontroli wersji automatycznie wykrywają konflikty i powiadamiają jednego z użytkowników o ich istnieniu. Reszta jest w rękach człowieka, musi on ręcznie rozwiązać (ang. resolve) konflikt i poinformować o tym system kontroli wersji.
Sposób na zadeklarowanie wyłączności na zmiany w danym pliku lub katalogu. Na przykład: "Nie mogę zrobić commitu moich zmian w stronach WWW. Wygląda na to, że Alfred założył blokadę na czas poprawek w obrazkach tła." Nie wszystkie systemy kontroli wersji pozwalają na stosowanie blokad, a z tych które pozwalają, nie wszystkie wymagają korzystania z nich. To dlatego, że równoległy wspólny rozwój jest standardem, a blokowanie plików przed zmianami innych jest (na ogół) sprzeczne z tą ideą.
Mówi się, że systemy kontroli wersji, które wymagają stosowania blokad aby wykonać commit, pracują w modelu blokada-modyfikacja-odblokowanie. Te, które ich nie wymagają stosują model kopia-modyfikacja-scalanie. Doskonałe wyjaśnienie i porównanie obu modeli można znaleźć w http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html. Na ogół model kopia-modyfikacja-scalanie jest lepszy dla rozwoju otwartego oprogramowania, i wszystkie systemy kontroli wersji omówione w tym rozdziale wspierają taki model.
As of this writing, the two most popular version control systems in the free software world are Concurrent Versions System (CVS, http://www.cvshome.org/) and Subversion (SVN, http://subversion.tigris.org/).
CVS has been around for a long time. Most experienced developers are already familiar with it, it does more or less what you need, and since it's been popular for a long time, you probably won't end up in any long debates about whether or not it was the right choice. CVS has some disadvantages, however. It doesn't provide an easy way to refer to multi-file changes; it doesn't allow you to rename or copy files under version control (so if you need to reorganize your code tree after starting the project, it can be a real pain); it has poor merging support; it doesn't handle large files or binary files very well; and some operations are slow when large numbers of files are involved.
None of CVS's flaws is fatal, and it is still quite popular. However, in the last few years the more recent Subversion has been gaining ground, especially in newer projects.[17]. If you're starting a new project, I recommend Subversion.
On the other hand, since I'm involved in the Subversion project, my objectivity might reasonably by questioned. And in the last few years a number of new open-source version control systems have appeared. Dodatek A, Wolne Systemy Kontroli Wersji (VCS) lists all the ones I know of, in rough order of popularity. As the list makes clear, deciding on a version control system could easily become a lifelong research project. Possibly you will be spared the decision because it will be made for you by your hosting site. But if you must choose, consult with your other developers, ask around to see what people have experience with, then pick one and run with it. Any stable, production-ready version control system will do; you don't have to worry too much about making a drastically wrong decision. If you simply can't make up your mind, then go with Subversion. It's fairly easy to learn, and is likely to remain a standard for at least a few years.
The recommendations in this section are not targeted toward a particular version control system, and should be simple to implement in any of them. Consult your specific system's documentation for details.
Keep not only your project's source code under version control, but also its web pages, documentation, FAQ, design notes, and anything else that people might want to edit. Keep them right next to the source code, in the same repository tree. Any piece of information worth writing down is worth versioning—that is, any piece of information that could change. Things that don't change should be archived, not versioned. For example, an email, once posted, does not change; therefore, versioning it wouldn't make sense (unless it becomes part of some larger, evolving document).
The reason versioning everything together in one place is important is so people only have to learn one mechanism for submitting changes. Often a contributor will start out making edits to the web pages or documentation, and move to small code contributions later, for example. When the project uses the same system for all kinds of submissions, people only have to learn the ropes once. Versioning everything together also means that new features can be committed together with their documentation updates, that branching the code will branch the documentation too, etc.
Don't keep generated files under version control. They are not truly editable data, since they are produced programmatically from other files. For example, some build systems create configure based on the template configure.in. To make a change to the configure, one would edit configure.in and then regenerate; thus, only the template configure.in is an "editable file." Just version the templates—if you version the result files as well, people will inevitably forget to regenerate when they commit a change to a template, and the resulting inconsistencies will cause no end of confusion.[18]
The rule that all editable data should be kept under version control has one unfortunate exception: the bug tracker. Bug databases hold plenty of editable data, but for technical reasons generally cannot store that data in the main version control system. (Some trackers have primitive versioning features of their own, however, independent of the project's main repository.)
The project's repository should be browsable on the Web. This means not only the ability to see the latest revisions of the project's files, but to go back in time and look at earlier revisions, view the differences between revisions, read log messages for selected changes, etc.
Browsability is important because it is a lightweight portal to project data. If the repository cannot be viewed through a web browser, then someone wanting to inspect a particular file (say, to see if a certain bugfix had made it into the code) would first have to install version control client software locally, which could turn their simple query from a two-minute task into a half-hour or longer task.
Browsability also implies canonical URLs for viewing specific revisions of files, and for viewing the latest revision at any given time. This can be very useful in technical discussions or when pointing people to documentation. For example, instead of saying "For tips on debugging the server, see the www/hacking.html file in your working copy," one can say "For tips on debugging the server, see http://svn.collab.net/repos/svn/trunk/www/hacking.html," giving a URL that always points to the latest revision of the hacking.html file. The URL is better because it is completely unambiguous, and avoids the question of whether the addressee has an up-to-date working copy.
Some version control systems come with built-in repository-browsing mechanisms, while others rely on third-party tools to do it. Three such tools are ViewCVS (http://viewcvs.sourceforge.net/), CVSWeb (http://www.freebsd.org/projects/cvsweb.html), and WebSVN (http://websvn.tigris.org/). The first works with both CVS and Subversion, the second with CVS only, and the third with Subversion only.
Every commit to the repository should generate an email showing who made the change, when they made it, what files and directories changed, and how they changed. The email should go to a special mailing list devoted to commit emails, separate from the mailing lists to which humans post. Developers and other interested parties should be encouraged to subscribe to the commits list, as it is the most effective way to keep up with what's happening in the project at the code level. Aside from the obvious technical benefits of peer review (see „Practice Conspicuous Code Review”), commit emails help create a sense of community, because they establish a shared environment in which people can react to events (commits) that they know are visible to others as well.
The specifics of setting up commit emails will vary depending on your version control system, but usually there's a script or other packaged facility for doing it. If you're having trouble finding it, try looking for documentation on hooks, specifically a post-commit hook, also called the loginfo hook in CVS. Post-commit hooks are a general means of launching automated tasks in response to commits. The hook is triggered by an individual commit, is fed all the information about that commit, and is then free to use that information to do anything—for example, to send out an email.
With pre-packaged commit email systems, you may want to modify some of the default behaviors:
Some commit mailers don't include the actual diffs in the email, but instead provide a URL to view the change on the web using the repository browsing system. While it's good to provide the URL, so the change can be referred to later, it is also very important that the commit email include the diffs themselves. Reading email is already part of people's routine, so if the content of the change is visible right there in the commit email, developers will review the commit on the spot, without leaving their mail reader. If they have to click on a URL to review the change, most won't do it, because that requires a new action instead of a continuation of what they were already doing. Furthermore, if the reviewer wants to ask something about the change, it's vastly easier to hit reply-with-text and simply annotate the quoted diff than it is to visit a web page and laboriously cut-and-paste parts of the diff from web browser to email client.
(Of course, if the diff is huge, such as when a large body of new code has been added to the repository, then it makes sense to omit the diff and offer only the URL. Most commit mailers can do this kind of limiting automatically. If yours can't, then it's still better to include diffs, and live with the occasional huge email, than to leave the diffs off entirely. Convenient reviewing and commenting is a cornerstone of cooperative development, much too important to do without.)
The commit emails should set their Reply-to header to the regular development list, not the commit email list. That is, when someone reviews a commit and writes a response, their response should be automatically directed toward the human development list, where technical issues are normally discussed. There are a few reasons for this. First, you want to keep all technical discussion on one list, because that's where people expect it to happen, and because that way there's only one archive to search. Second, there might be interested parties not subscribed to the commit email list. Third, the commit email list advertises itself as a service for watching commits, not for watching commits and occasional technical discussions. Those who subscribed to the commit email list did not sign up for anything but commit emails; sending them other material via that list would violate an implicit contract. Fourth, people often write programs that read the commit email list and process the results (for display on a web page, for example). Those programs are prepared to handle consistently-formatted commit emails, but not inconsistent human-written mails.
Note that this advice to set Reply-to does not contradict the recommendations in „Wielka debata o nagłówek Reply-to” earlier in this chapter. It's always okay for the sender of a message to set Reply-to. In this case, the sender is the version control system itself, and it sets Reply-to in order to indicate that the appropriate place for replies is the development mailing list, not the commit list.
Non-expert version control users are sometimes a bit afraid of branching and merging. This is probably a side effect of CVS's popularity: CVS's interface for branching and merging is somewhat counterintuitive, so many people have learned to avoid those operations entirely.
If you are among those people, resolve right now to conquer any fears you may have and take the time to learn how to do branching and merging. They are not difficult operations, once you get used to them, and they become increasingly important as a project acquires more developers.
Branches are valuable because they turn a scarce resource—working room in the project's code—into an abundant one. Normally, all developers work together in the same sandbox, constructing the same castle. When someone wants to add a new drawbridge, but can't convince everyone else that it would be an improvement, branching makes it possible for her to go to an isolated corner and try it out. If the effort succeeds, she can invite the other developers to examine the result. If everyone agrees that the result is good, they can tell the version control system to move ("merge") the drawbridge from the branch castle over to the main castle.
It's easy to see how this ability helps collaborative development. People need the freedom to try new things without feeling like they're interfering with others' work. Equally importantly, there are times when code needs to be isolated from the usual development churn, in order to get a bug fixed or a release stabilized (see „Stabilizing a Release” and „Maintaining Multiple Release Lines” in Rozdział 7, Packaging, Releasing, and Daily Development) without worrying about tracking a moving target.
Use branches liberally, and encourage others to use them. But also make sure that a given branch is only active for exactly as long as needed. Every active branch is a slight drain on the community's attention. Even those who are not working in a branch still maintain a peripheral awareness of what's going on in it. Such awareness is desirable, of course, and commit emails should be sent out for branch commits just as for any other commit. But branches should not become a mechanism for dividing the development community. With rare exceptions, the eventual goal of most branches should be to merge their changes back into the main line and disappear.
Merging has an important corollary: never commit the same change twice. That is, a given change should enter the version control system exactly once. The revision (or set of revisions) in which the change entered is its unique identifier from then on. If it needs to be applied to branches other than the one on which it entered, then it should be merged from its original entry point to those other destinations—as opposed to committing a textually identical change, which would have the same effect in the code, but would make accurate bookkeeping and release management impossible.
The practical effects of this advice differ from one version control system to another. In some systems, merges are special events, fundamentally distinct from commits, and carry their own metadata with them. In others, the results of merges are committed the same way other changes are committed, so the primary means of distinguishing a "merge commit" from a "new change commit" is in the log message. In a merge's log message, don't repeat the log message of the original change. Instead, just indicate that this is a merge, and give the identifying revision of the original change, with at most a one-sentence summary of its effect. If someone wants to see the full log message, she should consult the original revision.
The reason it's important to avoid repeating the log message is that log messages are sometimes edited after they've been committed. If a change's log message were repeated at each merge destination, then even if someone edited the original message, she'd still leave all the repeats uncorrected—which would only cause confusion down the road.
The same principle applies to reverting a change. If a change is withdrawn from the code, then the log message for the reversion should merely state that some specific revision(s) is being reverted, not describe the actual code change that results from the reversion, since the semantics of the change can be derived by reading the original log message and change. Of course, the reversion's log message should also state the reason why the change is being reverted, but it should not duplicate anything from the original change's log message. If possible, go back and edit the original change's log message to point out that it was reverted.
All of the above implies that you should use a consistent syntax for referring to revisions. This is helpful not only in log messages, but in emails, the bug tracker, and elsewhere. If you're using CVS, I suggest "path/to/file/in/project/tree:REV", where REV is a CVS revision number such as "1.76". If you're using Subversion, the standard syntax for revision 1729 is "r1729" (file paths are not needed because Subversion uses global revision numbers). In other systems, there is usually a standard syntax for expressing the changeset name. Whatever the appropriate syntax is for your system, encourage people to use it when referring to changes. Consistent expression of change names makes project bookkeeping much easier (as we will see in Rozdział 6, Communications and Rozdział 7, Packaging, Releasing, and Daily Development), and since a lot of the bookkeeping will be done by volunteers, it needs to be as easy as possible.
See also „Releases and Daily Development” in Rozdział 7, Packaging, Releasing, and Daily Development.
Most version control systems offer a feature whereby certain people can be allowed or disallowed from committing in specific sub-areas of the repository. Following the principle that when handed a hammer, people start looking around for nails, many projects use this feature with abandon, carefully granting people access to just those areas where they have been approved to commit, and making sure they can't commit anywhere else. (See „Prawo zapisu” in Rozdział 8, Zarządzanie ochotnikami for how projects decide who can commit where.)
There is probably little harm done by exercising such tight control, but a more relaxed policy is fine too. Some projects simply use an honor system: when a person is granted commit access, even for a sub-area of the repository, what they actually receive is a password that allows them to commit anywhere in the project. They're just asked to keep their commits in their area. Remember that there is no real risk here: in an active project, all commits are reviewed anyway. If someone commits where they're not supposed to, others will notice it and say something. If a change needs to be undone, that's simple enough—everything's under version control anyway, so just revert.
There are several advantages to the relaxed approach. First, as developers expand into other areas (which they usually will if they stay with the project), there is no administrative overhead to granting them wider privileges. Once the decision is made, the person can just start committing in the new area right away.
Second, expansion can be done in a more fine-grained manner. Generally, a committer in area X who wants to expand to area Y will start posting patches against Y and asking for review. If someone who already has commit access to area Y sees such a patch and approves of it, they can just tell the submitter to commit the change directly (mentioning the reviewer/approver's name in the log message, of course). That way, the commit will come from the person who actually wrote the change, which is preferable from both an information management standpoint and from a crediting standpoint.
Last, and perhaps most important, using the honor system encourages an atmosphere of trust and mutual respect. Giving someone commit access to a subdomain is a statement about their technical preparedness—it says: "We see you have expertise to make commits in a certain domain, so go for it." But imposing strict authorization controls says: "Not only are we asserting a limit on your expertise, we're also a bit suspicious about your intentions." That's not the sort of statement you want to make if you can avoid it. Bringing someone into the project as a committer is an opportunity to initiate them into a circle of mutual trust. A good way to do that is to give them more power than they're supposed to use, then inform them that it's up to them to stay within the stated limits.
The Subversion project has operated on the honor system way for more than four years, with 33 full and 43 partial committers as of this writing. The only distinction the system actually enforces is between committers and non-committers; further subdivisions are maintained solely by humans. Yet we've never had a problem with someone deliberately committing outside their domain. Once or twice there's been an innocent misunderstanding about the extent of someone's commit privileges, but it's always been resolved quickly and amiably.
Obviously, in situations where self-policing is impractical, you must rely on hard authorization controls. But such situations are rare. Even when there are millions of lines of code and hundreds or thousands of developers, a commit to any given code module should still be reviewed by those who work on that module, and they can recognize if someone committed there who wasn't supposed to. If regular commit review isn't happening, then the project has bigger problems to deal with than the authorization system anyway.
In summary, don't spend too much time fiddling with the version control authorization system, unless you have a specific reason to. It usually won't bring much tangible benefit, and there are advantages to relying on human controls instead.
None of this should be taken to mean that the restrictions themselves are unimportant, of course. It would be bad for a project to encourage people to commit in areas where they're not qualified. Furthermore, in many projects, full (unrestricted) commit access has a special status: it implies voting rights on project-wide questions. This political aspect of commit access is discussed more in „Who Votes?” in Rozdział 4, Social and Political Infrastructure.
[17] See http://cia.vc/stats/vcs and http://subversion.tigris.org/svn-dav-securityspace-survey.html for evidence of this growth.
[18] For a different opinion on the question of versioning configure files, see Alexey Makhotkin's post "configure.in and version control" at http://versioncontrolblog.com/2007/01/08/configurein-and-version-control/.