There is a common misconception that EditLive's track changes functionality is intended to be a substitute for the version history built into most content management systems. In reality, the two systems work together to achieve different aims.
Version history is the corporate compliance that you need, track changes is the collaboration that you want.
So where version history precisely tracks every change so that you can ensure accountability, track changes puts users in control, giving them a tool they can use to highlight important changes that need review. One of the common problems people have with version history is that when you make formatting changes to a large section of the document, that entire section shows up as a change and smaller changes to the actual content are often missed. With track changes, the author making the change can leave track changes off while making the formatting changes and then turn it on so just the important content changes are marked as changed. This ensures the reviewer can see the important changes and consider them appropriately.
Track changes also handles multiple people collaborating on a single document at once, with each person's changes being shown in a separate color it's easy to see who changed what. While version history can reveal this information by looking at what changed in each individual revision, but track changes allows you to see that information altogether in one place. When documents go through an extended collaboration process this can be extremely useful. You can also accept and reject track changes during the collaboration process as consensus is formed and the document takes shape, again focusing authors on just the changes that really matter, regardless of which version the change was made in.
Finally, the track changes data is shown right in the editing interface so users don't have to flip between editing the document and reviewing the previous changes.
So how does track changes work with version history at the technical level? Seamlessly usually. The track changes data is stored right in the HTML so it's versioned along with the content without any changes to the CMS. Additionally, the track changes mark up is designed to be completely hidden when viewed in a browser so you can see what the intended final version of the document was without the track changes markup getting in the way. We've also documented the track changes format so you can parse it and manipulate it in any way you want (it's based on the open document format's track changes but modified to work with HTML instead of ODF).
If you want to see track changes in action try out the EditLive Demo.