Forks in versioning content management

Google Search: fork
A fork is when a single original is edited twice, making two distinct new versions from the original. I've been considering what it would take to make a versioning content management system. I think important features of a content management system include:

• Versioning
• Embargo/Expiration of content (the arrival and departure of a content item should be able to be controlled chronologically)
• Context Awareness (content items should be aware of what contains them and what is linking to them)

The tricky part I'm thinking about now is forks in versioning. Maybe I should just ignore forking at the data storage layer? How could the application layer intellegently deal with forks within the same content item?

Hmm., Nukes

As you can see, the Nukes engine has a notion of versioning. This feature is not present in the original PostNuke engine. The persistence engine of JBoss uses a feature that increments the version and it keeps old versions as long as you want them. This way you can rollback in case you missed something. This is very useful as you work on a live web site. Also, the makeProd toggle enables you to select which version will be publicly displayed to your visitors.

I wonder what that looks like at a database level.