I’m thinking it would be nice with some sort of version control of a document. Let’s say I have a document that is published. And then I decide to make some changes to that document, but I’d like to test it a bit before I republish it (aka version 2).
The same goes for a system that you have other users on a team working in a document that you are creating. Also here some sort of version control system could benefit you as the developer, because you can make changes, and then update the document for all users…
I do see potential pitfalls like when to people make different changes at the same time to the document (not just adding or changing data in a database, but the actual document structure)…
Do my thoughts here make sense?
Perhaps a simple way would be to duplicate a document making it private only for you. Make the changes you want, and then perhaps a way to merge it with the Real document, so tables in the real document stays the same, but new data from your private source is merged in ? Is this a liable option?
I guess at the same time I’m writing this as a suggestion, I am just as curious as to how the rest of you Codans solve this, or perhaps it’s not even an issue for you? Then please elaborate
Great suggestion, Christian.
I have the same thought of having version control for the document, as it would make my job much much easier.
I’m building Coda doc for my client with incremental approach, but it’s been a struggle when I want to add test data to test new features without breaking the current system.
The current approach I have is to create a hidden page (page version 2) and work on that page. When I want to add test data, I will create a copy of that doc. When I’m ready to realize new feature, I will also need to check button with hyperlink to make sure it points to new version page.
I would love to know if there’s any better approach. And for sure, having doc version control or having development mode/environment will be the best option.
It would be of great interest to me (and probably others too) to know more details of your setup @Pablo_DV .
Is it a manual job to bring all the people over to the new document, or is it an automated process? I’d like to hear more about this system. It looks interesting.
Unfortunately all steps are manual except for the copying of the data, and even that one you have to build it your self tailored to your data model. Coda has many strengths, but this is not one of them.
The “problem” with Coda is that it has an extremely tight integration between data and function.
That makes any kind of version management (word, spreadsheet, SharePoint approach) or change management (software system approach) very complicated.
Other than Coda’s current version history, I doubt that there will be a “standard” solution to this soon.
Reasons:
do you want to do version management on data?
This is typically what you want to do in a wiki or hub environment. The next question would be whether you want to version manage parts of the doc, or the entire doc. Very often in this scenario one would want to update certain sections of the doc. E g. When you have a policy and procedures hub.
the other extreme is whether you want version management on your functionality?
This would apply in circumstances where your Coda doc is more like an app. Since Coda does not have DEV, QA and PRD environments, you would need to simulate it using an approach like that of @Pablo_DV above.
another scenario is where you build a doc, sell/ lease it to people, but want to keep updating content, functionality, or both.
Consideration here is whether everybody have to accept the changes, or whether they can opt out
Another factor to take into account is whether you want version management for backup purpose, or as a development quality assurance process.
As I said, I don’t think we will see a solution to the above wide ranging requirements soon. It is up to the individual doc maker to decide what their exact requirement is and put in place business and technical processes around that
I agree with you. It is some challenging thoughts as to how to actually pull something like that off. So in reality, I belive you are completely right.
I am thinking however that Coda internally must have run into some of these issues, and therefor I believe they should be able to perhaps contribute to some valid “best practices” or perhaps some of the you (the many Codans with great experience) how do you solve these issues in a managable way?
I see that I will be running in to this exact situation, and that is kind of the whole reason for me to post this issue here in the hope to get some good ideas of how I should proceed.
I have started a document where I fleshed out some of the scenarios that would need to be considered. I have also started adding some suggestion on some of the simpler scenarios.
