Three kinds of situations can cause this: 1) Debris from a failed commit is littering
your working copy; 2) Mixed revisions; 3) You might be genuinely out of date. The solution
depends on your circumstances.
- Debris from a failed commit could be littering your working copy. A failed
commit can occur between the time the new revision was added in the server and
the time your client performed its post-commit admin tasks (including refreshing
your local text-base copy). This might happen for various reasons, including
(rarely) problems in the database back end or (more commonly) network dropouts
at exactly the wrong time. If this happens, it's possible that you have already
committed the changes you are trying to commit. You can use 'svn log -rHEAD' to
see if your supposed-failed commit actually succeeded. If it did, run 'svn
revert' to revert your local changes, then run 'svn update' to get your own
changes back from the server. (Note that only 'svn update' brings your local
copies up-to-date; revert doesn't do that.)
- Mixed revisions could also cause this problem. When Subversion commits, the
client only bumps the revision numbers of the nodes the commit touches, not all
nodes in the working copy. This means that in a single working copy, the files
and subdirectories might be at different revisions, depending on when you last
committed them. In certain operations (for example, directory property
modifications), if the repository has a more recent version of the node, the
commit will be rejected, to prevent data loss. See The Limitations of Mixed
Revisions in the Version Control with Subversion for details. You can fix the
problem by running 'svn update' in the working copy.
- You might be genuinely out of date - that is, you're trying to commit a change
to a file that has been changed by someone else since you last updated your copy
of that file. Again, 'svn update' is the way to fix this.