Find checkout history for SVN working folder

Question

We have an intranet site backed by SVN, such that the site is a checkout out copy of the repository (working folder used only by IIS). Something on the site has been causing problems today, and I want to know how to find out what was checked out to that working folder in the last 48 hours.

Update: If there's an option I need to turn on to enable this in the future, what is it?

Also, as a corollary question, if I have to use the file creation time, how can I do that quickly in a recursive manner for a large folder?

---

If I have to check creation times, then this question will be helpful to the solution as well.

Answer 1

You could use creation-dates on the local files. You can't use modification-dates because Subversion sets those to last-changed upon checkout.

Also Subversion can log checkouts, but that's server-side

Answer 2

Depending how you access your SVN repo - if you're accessing it as file:// URLs, I think you're out of luck. But if you're using svnserve, or one of the HTTP gateways, you should be able to check your server logs for access to the SVN urls.

Answer 3

I would run a svn st in the web folder (to find any files that are changed since the checkout) and compare that to the repository.

Answer 4

All the code in the web folder should be backed by SVN commits, shouldn't it?

If this is the case you should easily be able to track the problem down just by looking through your SVN logs at the last few changes that got committed. svn info will tell you which revision the working copy currently is at, so you know where to start looking

Once you track down the commit with the bug in it, you can use svn blame to find the person that did it, and explain to them what they overlooked and how they caused the bug. Then you can make them buy everyone lunch for screwing up the site.

If you have locally modified/added any files which aren't in SVN, then svn stat and svn diff will show you what those changes are, so you can figure out if they are causing the problem too. You should then revert those changes so your working copy is a clean checkout, or commit the changes into the repository.

There's nothing worse than trying to track down a bug in your code only to find out 3 hours later that the bug is not actually in any of your code, but in some stupid local tweak someone made in the working copy that never got committed :-(