Tar wrappers in subversion??!?!?!
Bill Bumgarner explains why Subversion needs opaque collections. Another example would be any development project that relies on third party libraries (or code, servers, etc. – for example, freeze_edge in a Rails project). You want to keep the version of the library you use (and have tested against your code) under version control. Currently, the version of every file in the library gets tracked separately (technically, the directory version that this version is in). For most purposes, this is useless. If you need to update versions, you can’t just update: you have to remove the old version, replace it, and re-add the new version. Otherwise, svn will get confused. For most purposes, this is worse than useless: If the directory is managed by an application, svn will get confused. If the directory is updated by software, svn will get confused.
Updated. Thanks to Jamie for pointing out the ambiguity in my original description of how svn tracks the versions each file separately. Jamie also pointed out something that I think bears consideration: most of the work on this needs to happen on the client. All the server needs to know is that a specific directory node and everything below it are handled in the same way as a single file. You could do a cheap hack of a solution without the repository knowledge by adding a client command which automatically removes the old version of a directory and inserts the new one. However, this wouldn’t handle the case where the directory’s contents are generated by software.