One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa. Just because you’re ready to submit new changes to the repository doesn’t mean you’re ready to receive changes from other people. And if you have new changes still in progress, svn update should gracefully merge repository changes into your own, rather than forcing you to publish them.

The main side effect of this rule is that it means a working copy has to do extra bookkeeping to track mixed revisions as well as be tolerant of the mixture. It’s made more complicated by the fact that directories themselves are versioned.

For example, suppose you have a working copy entirely at revision 10. You edit the file foo.html and then perform an svn commit, which creates revision 15 in the repository. After the commit succeeds, many new users would expect the working copy to be entirely at revision 15, but that’s not the case! Any number of changes might have happened in the repository between revisions 10 and 15. The client knows nothing of those changes in the repository, since you haven’t yet run svn update, and svn commit doesn’t pull down new changes. If, on the other hand, svn commit were to automatically download the newest changes, it would be possible to set the entire working copy to revision 15—but then we’d be breaking the fundamental rule of “push” and “pull” remaining separate actions. Therefore, the only safe thing the Subversion client can do is mark the one file—foo.html—as being at revision 15. The rest of the working copy remains at revision 10. Only by running svn update can the latest changes be downloaded and the whole working copy be marked as revision 15.

The fact is, every time you run svn commit your working copy ends up with some mixture of revisions. The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions. Even if you’re the only person using the repository, you will still see this phenomenon. To examine your mixture of working revisions, use the svn status command with the --verbose option (see See an overview of your changes for more information).

Often, new users are completely unaware that their working copy contains mixed revisions. This can be confusing, because many client commands are sensitive to the working revision of the item they’re examining. For example, the svn log command is used to display the history of changes to a file or directory (see Generating a List of Historical Changes). When the user invokes this command on a working copy object, he expects to see the entire history of the object. But if the object’s working revision is quite old (often because svn update hasn’t been run in a long time), the history of the older version of the object is shown.

If your project is sufficiently complex, you’ll discover that it’s sometimes nice to forcibly backdate (or update to a revision older than the one you already have) portions of your working copy to an earlier revision; you’ll learn how to do that in Chapter 2. Perhaps you’d like to test an earlier version of a submodule contained in a subdirectory, or perhaps you’d like to figure out when a bug first came into existence in a specific file. This is the “time machine” aspect of a version control system—the feature that allows you to move any portion of your working copy forward and backward in history.

However you make use of mixed revisions in your working copy, there are limitations to this flexibility.

First, you cannot commit the deletion of a file or directory that isn’t fully up to date. If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you’ve not yet seen.

Second, you cannot commit a metadata change to a directory unless it’s fully up to date. You’ll learn about attaching “properties” to items in Chapter 3. A directory’s working revision defines a specific set of entries and properties, and thus committing a property change to an out-of-date directory may destroy properties you’ve not yet seen.