B-Maker stories

Feature storyVersions

No more final-final.docx.

Rewriting is part of writing. The problem begins when every rewrite becomes another file and nobody remembers which “final” is actually current.

B-Maker full-screen comparison of two text versions
The basic idea

A chapter stays one chapter. Revisions live inside it as named versions, so structure and revision history do not drift apart.

The familiar folder problem

A rewrite often starts innocently: duplicate the file before making a large change. Then comes chapter-7-v2.docx, then chapter-7-final.docx, then chapter-7-final-edited.docx. After enough iterations, the filename is doing work that should belong to the writing system.

The deeper problem is not ugly names. It is uncertainty. Which file is current? What changed between two versions? Is the editor commenting on the same text you are editing now? Can you safely return to the older ending without reconstructing it from backups?

Step 1. Keep the manuscript structure stable

In B-Maker, a scene, chapter, or article remains the same structural element while its text can have several versions. The manuscript tree does not need duplicate chapters called “old,” “new,” and “really new.”

Create a new version when you are about to make a meaningful rewrite. Give it a useful name: “Shorter opening,” “Editor pass,” “Alternative ending,” or simply a date if that is enough context.

One B-Maker chapter with several named revisions and a clear current version

Step 2. Rewrite without deleting the previous answer

A difficult rewrite is easier when the earlier text still exists. You can cut aggressively, change the point of view, move a scene, or test a shorter argument without treating every edit as irreversible.

This changes behaviour in a small but important way: you can experiment instead of protecting yesterday's text just because recovering it would be annoying.

Step 3. Compare instead of relying on memory

When two revisions feel different but you cannot immediately explain why, compare them directly. The comparison view makes additions and removals visible without opening two separate files and scrolling them manually.

This is useful not only for proofreading. It helps answer editorial questions: Did the rewrite actually become shorter? Which example disappeared? Did the new opening remove a piece of context that was still needed later?

Screenshot: compare two named versionsFull comparison view of the same chapter. Use a short passage where additions and removals are visually obvious.assets/img/bmaker/bmaker-story-version-02.webp

Step 4. Lock what should stop moving

Some versions are not merely old; they are reference points. Perhaps this is the text sent to an editor, the approved version for publication, or a milestone you want to preserve exactly as it was.

Lock that version. It opens read-only, which reduces the risk of quietly changing the reference copy while believing you are working on the next revision.

Step 5. Keep comments with the text they belong to

Revision is rarely just a sequence of files. It also contains decisions: why a paragraph exists, what still needs checking, what a reviewer questioned. Comments can belong to the whole text or to a specific passage, keeping the editorial conversation close to the material.

A locked B-Maker version with passage and general comments

Versioning should reduce fear, not add process

This is not software-development Git transplanted into a writing application. A writer should not need commits, branches, merge strategies, or a source-control vocabulary to preserve an earlier draft.

The useful part of version control is simpler: know what is current, preserve what mattered, compare what changed, and experiment without destroying the previous state.

Related guides

Manuscript version management · How to organize a novel · From idea to chapter

Rewrite the chapter, not the filename.

Keep revisions inside the project and let the manuscript structure remain stable.

Open B-Maker Product overview