Thanks to the answer of @JeremyP, I started to search for "svn mixed revision working copy". There a detail explanation in chapter Version Control the Subversion Way of the svnbook.
Mixed-revision working copies
As a general principle, Subversion tries to be as flexible as possible. One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Subversion working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions.
Mixed revisions are normal
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.
Revision in SVN specifies the state at one point in time of all files and folders that were checked in a repository, and there is one history of revisions for the whole repository. But revision in CVS applies to individual file (not folder), and each file has a separate history of revisions.
Every time a commit is made in CVS, revision of each file is updated independently. Thus, a working copy in CVS is inherently in mixed-revision state. You can assign a common revision to all files by adding a commit with a specific revision (it must be larger than all existing revision). But it's easier to create a tag from the current state of the working copy (with each file in a different revision).
SVN commit works similarly, revision of recently committed files is higher than revision of remaining files. However, since revision is global in a repository, it's easy to update all files to the same revision with a command (
This observation makes me think that the idea of mixed revision working directory of SVN was based on CVS's behavior.
This feature is also in-line with design goal for SVN:
So CollabNet determined to write a new version control system from scratch, retaining the basic ideas of CVS, but without the bugs and misfeatures.
The original design team settled on some simple goals. They didn't want to break new ground in version control methodology, they just wanted to fix CVS. They decided that Subversion would match CVS's features and preserve the same development model, but not duplicate CVS's most obvious flaws. And although it did not need to be a drop-in replacement for CVS, it should be similar enough that any CVS user could make the switch with little effort.
SVN project also said the same:
Apache Subversion is a full-featured version control system originally designed to be a better CVS. Subversion has since expanded beyond its original goal of replacing CVS, but its basic model, design, and interface remain heavily influenced by that goal. Even today, Subversion should still feel very familiar to CVS users.