Table of Contents
The three cardinal virtues of a master technologist are: laziness, impatience, and hubris." —Larry Wall
This describes some of the theoretical pitfalls around the (possibly arrogant) notion that one can simply version directories just as one versions files.
To begin, recall that the Subversion repository is an array of trees. Each tree represents the application of a new atomic commit, and is called a revision. This is very different from a CVS repository, which stores file histories in a collection of RCS files (and doesn't track tree-structure.)
So when we refer to “revision 4 of foo.c” (written foo.c:4) in CVS, this means the fourth distinct version of foo.c—but in Subversion this means “the version of foo.c in the fourth revision (tree)”. It's quite possible that foo.c has never changed at all since revision 1! In other words, in Subversion, different revision numbers of the same versioned item do not imply different contents.
Nevertheless, the content of foo.c:4 is still well-defined. The file foo.c in revision 4 has specific text and properties.
Suppose, now, that we extend this concept to directories. If we have a directory DIR, define DIR:N to be “the directory DIR in the fourth revision.” The contents are defined to be a particular set of directory entries (dirents) and properties.
So far, so good. The concept of versioning directories seems fine in the repository—the repository is very theoretically pure anyway. However, because working copies allow mixed revisions, it's easy to create problematic use-cases.