How stable is Scroll Versions with large documentation sets?
We plan to use Scroll Versions for managing our end-user documentation for our software products. Eventually we expect to have 5,000+ topics. In a typical release maybe only 10-15% of these topics will be updated. Between releases we may have small day-to-day updates to fix minor issues, like correcting typos.
One of the key decisions we have to make before we begin is whether to organise the documentation into separate spaces, say a space for each product which seems to be a common approach, or whether to create one single space for everything.
To help us make this decision I would like some advice about how Scroll Versions performs with very large documentation sets.
Assuming we’ll have 5,000 plus topics, I would like to know if Scroll Versions is stable and capable of managing such a high volume of documentation or whether you recommend that we break the documentation up into separate spaces.
Secondly, if only 10% of topics have been changed in a particular version, when we go to publish that version does Scroll Versions process all 5,000 topics during the publishing process or just the 10% of topics that have changed?
Please let me have your thoughts/recommendations on what you think would work best — a single, large space or multiple smaller spaces — or is the plugin capable of dealing equally well with either of these options?
thanks for contacting us and your interest in Scroll Versions.
We have customers who manage up to 15.000 Confluence pages within one space with Scroll Versions, so theoretically 5000 pages should be no problem at all.
However splitting the docs in multiple spaces (=manage each product in its own space) would be an option (of course that depends on the similarity of your products and if you want to use the variant management feature).
When you only modify 10% of your pages before publishing, only these pages will be published. However to check which pages have been changed Scroll Versions needs to go through all pages (in your case 5000) and compare the content.
There's already a feature request to be able to publish single pages (see https://k15t.jira.com/browse/VSN-1219) and we are planning to have a closer look at this improvement in one of the next releases. However I can't give you an ETA on this improvement currently. Please sign up at https://k15t.jira.com/secure/Signup!default.jspa to watch, comment on or vote for this issue. You'll then get a notification once the feature is implemented.
So if you do not have much content that has to be reused in multiple docs of your different products, I'd suggest to have multiple spaces.
I hope that helps. If you want to discuss your use case in a more private matter, please send more details to firstname.lastname@example.org. That will automatically create a new ticket in our support system and we'll be happy to give some further insights.
if your content is unversioned, you could use the normal Confluence include macro to reuse the content from different spaces.
However, please note that this is only a workaround and not officially supported until we improved the functionality of the include plus macro: https://k15t.jira.com/browse/VSN-766.
The problem with using multiple spaces is that you cannot access an inclusions library (include+ macro) that's located in another space. Therefore reusing content is off the board as far as I know. I would like to be wrong about this as I would like to use Scroll Versions in conjunction with the subspaces addon.
Hey Nils, I wanted to check in on this thread.
My company is going to release a few new products, so we'll need to be able to publish 3 documentation sites, as opposed to the one from which we're currently publishing (private master).
Obviously https://k15t.jira.com/browse/VSN-766 is still open, so I wanted to check and see if there were any newer alternatives for using one include library across multiple spaces. We need the content in the library to be versioned.
Thanks for asking.
You're right, the mentioned issue is still open, as we did focus on other improvements the last couple of months.
We're aware that content reuse needs some further improvements and are planning to work on this topic in one of the next releases.
For now there's no workaround available, but we'll improve the current behavior as soon as possible.
As you've voted the mentioned issue, you'll get a notification for every change.
If you've any further feedback regarding the topic of "content reuse" in general, or what you would like us to have a look at when diving deeper into that, please let us know.
I am not sure what process is used to find what to publish, but wouldn't it be easy to store the last publishing timestamp, check what pages have last modified timestamp after that stored timestamp, apply other qualification criteria on this shortlist of pages (variants,etc.) and publish? We have space with 10k pages. If we change 100 in a version, what's the point in comparing all 10k. Just look at the timestamp and publish only 100. Just a suggestion...
Hi Amit. Thanks for your suggestion, I have added it as an internal comment to the feature request of publishing single pages.
Even though this approach would work for a certain use-case, there are use-cases for which it won't. There are customers who publish different versions from the same master space to other spaces. The internal logic would have to keep the record of all target spaces the master space published to.
Also, one of the features of Scroll Versions is that when publishing, the content that was modified in the target space (accidentally or deliberately) will be overwritten. In this case, all pages in the master and target space would have to be compared regardless of the timestamp of the last publish.
Another use-case where this won't work is when a user removes a target space completely and creates a brand new one from scratch with the same space key. If I would publish to such target space, I would expect Scroll Versions to publish all pages from the source space. That means the logic with the timestamp has to be omitted or an additional logic has to be in place to control the logic with the timestamps (to detect when the space created and to compare it with the last edited timestamp).
To summarise, we are always reviewing the code in order to optimise publishing. It's just that we have to accommodate so many different use-cases and possible variations, that certain approaches might not work for the majority of use-cases. Thanks again, Amit, for your suggestion.
Please sign in to leave a comment.