How stable is Scroll Versions with large documentation sets?

Comments

11 comments

  • Avatar
    Nils Bier

    Hi Caren,

    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 support@k15t.com. That will automatically create a new ticket in our support system and we'll be happy to give some further insights.

    Best,Nils

  • Avatar
    Mary Connor

    But what if I do want to reuse content across products, and those products have different version numbering? 

  • Avatar
    Nils Bier

    Hi Mary,

    thanks for contacting us.

    Would your reused content be versioned, or would it be the same throughout all versions?

    Best,
    Nils

  • Avatar
    Mary Connor

    I'm guessing that having it be the same throughout is the far simpler case? I'd be willing to live with that limitation. :-)

    Types of content to share at minimum: glossary terms, diagrams, warnings and cautions, legal notices, basic shared procedures.

  • Avatar
    Nils Bier

    Hi Mary,

    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.

    Best,Nils

  • Avatar
    Nigel Dawes

    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.

  • Avatar
    Matt Reiner (Edited )

    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.

  • Avatar
    Nils Bier

    Hi Matt,

    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.

    Cheers,
    Nils

  • Avatar
    Amit Kapoor

    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...

  • Avatar
    Roman Serazhiev

    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.

    Cheers,
    Roman.

  • Avatar
    Amit Kapoor

    And I was thinking of my use cases only :-) . Thank you Roman.

Please sign in to leave a comment.

Powered by Zendesk