Content Versioning#19

Allows users to see previous revisions of a content entry and compare two versions. Also allow jumping back to older versions.

This could be a per-model feature, we don’t necessarily want versionning for all models. Not sure if making it opt-in/out is necessary, could save some space/bandwith if people only use it when they really need to. What’s your current state of mind on this?

I agree that this should probably be an opt-in, per-model thing, especially to isolate any possible breaking changes to the existing query and mutation APIs.

I see content versioning as distinct layers of functionality, which could be implemented together or separately, depending on how people might actually use it.

1. Add a reserved field name to every model, like revisionId, which just tracks the revision count. Other than handling any possible conflicts with existing users, this shouldn’t break anybody’s code, and would add the benefit of tracking how many times a model has been saved (might be useful).
2. Start recording revisions on the backend. Exposing a revisionId input to the query and mutation API would give you basic version tracking, reverting, etc.
3. Enable/enforce conflict detection. Systems like CouchDB require every write operation (mutation) to provide a revisionId, and the server will reject any writes where they don’t match, because that means the client has old data. Supporting this on the server is simple (if revisionID‘s don’t match, throw version mismatch error), but it would require work on the client side to display the error and help the user resolve the conflict(s). GraphCMS could do that in its own client, and leave it up to customers to handle themselves if they want conflict detection.

You could probably implement point 1 pretty silently, unless some customers are already using the field name you choose. Implementing point 2 is a lot more work, but making a per-model checkbox to enable it would prevent confusing existing users.

I think point 3 is a bit tougher, but would also serve double duty in providing a mechanism to edit-lock content, which is critical to provide atomic safety in write-heavy environments. Heck, I only have a handful of editors on one of our teams, but they still mess up each other’s content on occasion (think multiple editors rushing to get a new article or issue out; it gets hectic). It would be nice to see GraphCMS prevent that (see request #40 ).

Question: should revisions cascade up or down relations? It’s much simpler to say no, but then you could no longer trust revision ID’s to reflect overall change status, making it useless for stuff like cache management.

Since posting the above comment, I’ve seen a few variations on questions about how to get distinct published vs. non-published results from the GraphCMS API. I think it would be good to plan feature sprints for this and #21 such that once versioning functionality is at least to step 2 from above, you refactor the content API to deliver the last published revision when asked for pubished content, and the most recent overall revision when asked for unpublished content.

If it were me, I would prioritize that ahead of adding the ability to diff, revert, track changes, fire hooks, etc. from revisions. I think way more customers would benefit from a legit publishing workflow that supports approval of non-public content. Frankly, it’ll probably bring in customers who might otherwise discount GraphCMS. Getting true content versioning will probably be the lion’s share of effort here anyways, as that’s no simple task.