Page 147 -

Subversion performs an atomic commit, which means that either all of the changes go into
the repository completely, or none of them make it at all. This way, the programmer does
not need to worry about only half of the changes making it into the repository. (Some
older version control systems suffered from that problem.)
Since multiple people can each check out their own working copies, they can all work on
the same file simultaneously. There is no limit to the number of times a file can be
checked out at once; any part of the repository can be checked out into multiple working
copies on multiple machines at the same time. If several people have files checked out of a
repository, it is likely that there are earlier versions of some files in some of their working
copies, and later versions in other ones.

If the repository has not changed since the working copy was checked out, then the user
can simply commit the change, and Subversion will update the repository. However, if the
repository has changed, Subversion will not allow the user to commit the changes just
yet—it will tell the user that the working copy is out-of-date. At this point, it is up to the
user to bring the working copy up-to-date by telling Subversion to update the working
copy. Subversion will then retrieve any changes that have been committed to the reposi-
tory since the working copy was checked out.

Often, most of the changes that have been committed to the repository since the working
copy was checked out are mergeable, meaning that none of the lines that changed in the
repository have changed in the working copy. When this happens, Subversion will update
all of the files in the working copy to reflect all of the changes that have been committed
to the repository.

However, if a conflict occurs, it is up to the user to resolve it. A conflict occurs when two
people (let’s call the second person Bob) introduce different changes to the same line in
the same file in their separate working copies. A conflict occurs when Alice and Bob both
need to make different changes to the same lines in the same file. They both check out the
file and make changes to it, and Alice commits it back to the repository first. But when
Bob attempts to commit the change to the repository, Subversion discovers that there is a
conflict. That conflict must be resolved in Bob’s working copy before it can be committed
to the repository.

To illustrate this idea, consider what would happen to the previous example (cookies.txt r47
in Table 7-2) if Alice committed her changes under different circumstances. Suppose she
checked out r23 (see Table 7-1), but Bob checked in r38 (shown in Table 7-3) before she
could commit her changes.

TABLE 7-3. cookies.txt r38 committed by Bob on April 26 (with M&Ms added)
2 1/4 cups flour 1 tsp baking soda 1/2 tsp salt
1 cup butter 3/4 cup sugar 3/4 cup brown sugar
1 tsp vanilla 2 eggs 2 cups chocolate chips
1 cup chopped M&Ms
Mix butter and sugars. Beat until creamy. Add vanilla. Beat in eggs, one at a time.
Mix in rest of ingredients. Drop by spoonfuls on cookie sheets. Bake at 350
degrees.

DESIGN AND PROGRAMMING 139