It doesn't track explicit directory renaming.
It knows each directory by its content, so it knows when a directory was renamed, without needing to be explicitly told.
It doesn't keep branch history - if it did, reflog (which is local and only kept for 30 days) wouldn't be needed.
Reflog is an essentially local thing, it shows where a branch used to point in a particular repository instance. It has little to do with history of the project, and often includes temporary commits that shouldn't be distributed.
It only allows unique tags - so if you want to mark every revision where buildbot succeded to make both update and rolling back easy - you are out of luck
You need some way to specify what you'd want to update or roll back to - what kind of use case are you thinking about? You could support a successful-build branch, for example, so that its tip points to the last successful build, and you could create merge commits with previous successful builds as first parents, for the purpose of linking together all successful builds in that branch.
Tracking path by their content is not always good... It couples content changes with intent changes. If I need to make a copy of directory and then make the copies slowly diverge until they have nothing in common, I may want to mark which is for original intent and which is spin-off.
Branch history is not an inherently local thing.
When I have feature branches for recurring tasks, I will probably call them always the same. I will sometimes merge them with trunk and sometimes spawn them from the new trunk state. Later, I may wish to check whether some change...
Follow-up to Journal article about politics and mindkilling. That post showed that people can be convinced that a view is correct by being told that their political party endorses it, even if their party actually opposes it. A similar, but stranger, effect, is that people can be convinced that a view is correct because their favorite software implements it - even if they have stated that the view is wrong just minutes ago.
Subversion is a popular version-control system used by software developers. The "repository" is where subversion stores the definitive copy of each file it is keeping track of. A "diff" is when you ask subversion to show you all differences between your new code, and the last version of that code that it knows was in the repository. A "tag" is when you associate a set of versions of different files together, in a way so that they can be easily compared against or reverted to, without creating something called a "branch".
I've had variants of this conversation about Subversion three times so far:
Me: [problem X] happened because Subversion doesn't let you diff against the repository.
Other: What?
Me: Subversion doesn't let you diff against the repository. It only diffs against its local copy of the repository, which it updates when you do a checkout, commit, or update. So it won't show you any changes that someone else has made to the code since then. You can never see what changes other people have made since your last commit, because to get the changes, you have to do an update; and the changes are added to your code without being shown to you, and a diff won't show them. So you just cross your fingers and hope their changes are compatible with yours.
Other: That's ridiculous! Subversion doesn't do that. That would defeat the whole purpose of version control. That would be idiotic.
Me: Really, it does that. I've tried it. Repeatedly. I've wasted days of work because of it.
Other: Nonsense. Of COURSE Subversion diffs against the repository.
Me: Try this: Create a new file foo in your checkout in directory X. Then svn add foo and svn commit foo. Check out the same repository in directory Y. Modify foo in directory X. svn commit foo. Then do an svn diff foo from directory Y.
[A few minutes later, after trying it:]
Other: Well, of COURSE Subversion doesn't diff against the repository. It's meant for large, distributed projects. You wouldn't want to have to do diffs over the web.
Me: Why?
Other: It would be too slow.
Me: You do checkouts and commits and updates over the web. Are they too slow?
Other: You want to diff against your previous version. It would be too confusing to see the changes other people have made, too.
Me: Three minutes ago you said it would be idiotic not to diff against the repository.
Other: Look, Subversion is an industry standard!
Me: Subversion doesn't even let you tag releases.
Other: Of COURSE Subversion lets you tag releases.
[Conversation eventually ends with Other explaining why you don't need to tag releases anyway.]
[P.S. - There is a very long syntax for svn diff that lets you specify full paths to the repository and your checkout directory. It can't mix paths and URLs, so you have to specify your checkout directory as a complete URL. No one that I know uses this syntax.]