Followup on SharePoint Versioning
Thanks to some fellow MVPs and co. I got more information on the whole versioning thing. As mentioned, Serge van den Oever posted a blog about it (being one of his bigger griped about versioned libraries). I spent the better part of yesterday morning with Microsoft going over it, trying out a dozen or so test scenarios and trying to come to a pretty complete understanding on what was happening and what it meant.
When your add a document to a versioned document library in SharePoint, the document is put into the SQL database and various bits of information are set (created date, modified date, etc.). When the next version of that document comes along, the current one (which is the one you address via the url that you might send out to people) is moved into a virtual folder (under a _vti_history directory) and the new copy is setup to replace the previous one (as far as addressing the file through a url is concerned).
The problem however basically breaks down to this. Using checkin/checkout will trigger a change in updating a previous version. The change isn't the content, just that move that happens when the current version is copied down into the _vti_history directory. If you simply upload the file (or save it directly using your Office 2003 client), then a new version is generated but the previous version's time and date stamp is left intact. It seems there's two paths here. One will update your previous versions timestamp, the other won't. I suspect (but haven't dug in deep enough with Reflector to see what's going on) that they're taking two different calls to do this (something like the difference between Copy and Move in a document library where one will copy the history and other doesn't).
Yeah, bugs the crap out of me. I'm currently working on a Contract Management System built in SharePoint so we're dealing with many versions of legal documents and the business user needs to know who modified what and when. We've been pushing them to use the checkout/edit/checkin cycle but now it looks like that might change as we can no longer tell the when part.
There was a recommendation by Dustin Miller to build an event handler for the library to get around this. That's great if you only have one handler and don't want to use 3rd party tools like Nintex's doclibs as there's a one handler per doclib restriction in effect. There is a new TODO on my very large list of SharePoint goodies to cook up now. An Event Handler Factory is needed for SharePoint that can invoke other event handlers or chain event handlers together. Seems like a fun thing to do (but feel free to build one yourself if you're so inclined).