Version Control with Subversion

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Summary

|

21

At first, it may not be entirely clear why this sort of flexibility is considered a feature,

and not a liability. After completing a commit to the repository, the freshly commit-

ted files and directories are at a more recent working revision than the rest of the

working copy. It looks like a bit of a mess. As demonstrated earlier, the working

copy can always be brought to a single working revision by running

svn update. Why

would someone deliberately want a mixture of working revisions?

Assuming your project is sufficiently complex, you’ll discover that it’s sometimes

nice to forcibly backdate portions of your working copy to an earlier revision; you’ll

learn how to do that in Chapter 3. Perhaps you’d like to test an earlier version of a

submodule, contained in a subdirectory, or perhaps you’d like to examine a number

of previous versions of a file in the context of the latest tree.

However you make use of mixed revisions in your working copy, there are limita-

tions to this flexibility.

First, you cannot commit the deletion of a file or directory which 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