## What's event sourcing? We talked about [events and what it means to record them](http://inside.traction.io/post/21773841438/we-event-stream-processing). Once you record events, you can also use this event log as a source for data. You can reconstruct the state of your application at a certain point in time, undo changes, insert things into the timeline and see how it affects later states or pick specific events and run them again. There are lots of use cases for event sources and today I want to tslk about one you likely already are familiar with, but might not have expected to belong to this topic: source code management. SCMs like GIT manage a list of file changesets (events) that are applied in a certain order to form the current state of the working copy. You can go back in time, fork the repo, insert changes, undo commits and cherry pick changes from history or other branches. ## So, what about it? Now I ask you to keep in mind this picture of a repository being a timeline and think about how often you go back, review changes, undo stuff that happened and perhaps even inserted changes to alter the history of what you're looking at right now. Doesn't this feel like time travel? We all know the great responsibility that comes with the power of this kind of event stream, but also the possibilities that go with it. Those possibilities could be transferred to your use of data, if you made use of event sourcing for this. I will talk about several of those use cases in the future so stay tuned, if you're curious.
