SVN allows each sub-folder in a working directory to be at a different revision. SVN used to put a folder (".svn") for metadata into each sub-folder, just like CVS did.

I wonder if SVN also copied from CVS the ability to work with different revisions in a working directory.


In subversion, a revision refers to a snapshot in time of the whole directory tree. You can have a mixed revision working copy, but the whole version number thing is fundamentally different to CVS.

The location(s) of .svn is of no importance in this discussion, it is just an implementation detail. When the working copy format was being decided, it was thought that the ability to pull out a subtree of the working copy and use it as a standalone working copy would be useful. This turned out not to be the case: when people needed a subtree they tended to checkout a new working copy with just that subtree. On the other hand, having .svn directories everywhere was a pain in the backside.

You can have mixed revision working copies but only because, when you commit files, you don't automatically update the working copy from the server. The principle is that Subversion won't pull files from the repository without your say so and therefore you necessarily end up with a mixed revision wc.

I can't think of any other practical use for the feature except to confuse newbies.

  • 2
    On the other hand, if this were an actual feature in SVN, and if it were also existing in CVS, then the answer would almost certainly be "Yes", since SVN was designed and developed by former CVS developers, explicitly as a "lessons learned, let's get it right the second time" kind of system. Jul 2 at 0:05
  • @jeremyp thanks for the answer. I searched for "mixed revision working copies" and found more explanation in chapter "Version Control the Subversion Way" (svnbook.red-bean.com/en/1.7/svn.basic.in-action.html) of the svnbook. It looks like this idea is not from CVS.
    – DungSaga
    Jul 4 at 17:25

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 (svn update).

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.