One automatic way to do this is through database-level DDL triggers. That is, for every change there is a trigger that saves the code obtained from EventData(). The DDL trigger inserts these into an external db, which also collects similar changes from several databases. Then it's a matter of matching the contents of the field that stores /EVENT_INSTANCE/TSQLCommand of EventData() with the source.

See an earlier post on this thread for code showing a simple DDL trigger example using EventData().

This solution will have the effect of limiting the source to be one file for each object in the db. There also has to be some consistency in naming db objects and their corresponding files in the VCS. Comparing in SQL itself is slow unless we use CLR routines. CLRs can do fast DIFF on source file and the contents of that field and produce a nice table of all objects in production that differ from the source.

This method will also have the benefit of using a variety of VCS and not tied to a specific product. If you have multiple version control systems, then create one CLR for each to encapsulate that VCS's diff commands. Within each VCS also there could be different ways to compare: binary, line-by-line, UNICODE, etc. You can encapsulate these as well in the CLR. At various times, we had to integrate VSS, SVN, GIT, and Mercurial. Each time only the CLR needed tweaking while keeping the rest of the SQL side and VCS side unchanged.

We can also answer the question: which version of the source matches the production? How many changes were made since then? Which objects had most changes? Since all these are tied to dates and times, simple undo and redo can be implemented as well.