title: Object versioning patterns
body: <p>I'm trying to model some of our objects in our domain and came across a problem that some of these objects could be versioned. i.e, user could create new object versions over a period of time. So, I need to model them in the program. I think that this is a common problem in SW design. </p>
  
  <p>Initially I jumped to the idea of mimicing source control versioning concepts and came up with a versioned object concept and methods like check-in, check-out etc. But, I get a feeling that it is not quite 'systematic' as I didn't explore patterns (i.e, I feel like committing sins like </p>
  
  <ul>
  <li>I didn't cover aspects like looking for more than one solution </li>
  <li>looking into literature which would give me more solid references etc). </li>
  </ul>
  
  <p>So, my current problem is that for a systematic modelling, I need to search for patterns which addresses the version modelling problem, preferrably in literature. And take the best out of it, of course.</p>
  
  <p>So, I googled for such patterns and only found a <a href="http://martinfowler.com/eaaDev/TemporalObject.html" rel="nofollow noreferrer">Temporal Object pattern</a>. But, I was not sure if this was really what I wanted. Do you guys have any suggestion on such patterns?</p>
  
  <p>[Self-Edit] Maybe I haven't described the problem well. You can see the problem similar to a source-control file-versioning problem. I have several types of objects (stored in database) that can have several versions. Inside my application I have to handle all these versions and also I will have to create new version of objects (which will eventually get stored in database). What I'm looking forward is some kind of cite-able pattern with which I can model the interfaces for accessing/modifying/adding new versions for these objects. The basic interface I could come up with is IVersionedObject with methods like checkout, checkin, undoCheckout etc. But, this is my own idea observing source control systems. I don't think it is a SW design pattern as such. So, looking forward for some very well documented design patterns for the above problem.</p>