Version Control

Software developers use the same term for tools that track changes to source code line by line. In a DAM it applies to whole binary files (images, videos, documents, design files), and the questions are simpler: which file is current, who replaced it, and what was there before.

Versions under one asset vs versions as separate files

Shared drives keep versions in file names: hero_final_v3_FINAL_approved(2).jpg. Every copy is a chance for someone to use the wrong one.

	Versions as separate files	Versions under one asset
Which file is current	Whichever copy someone believes is the latest	Always the asset's current version
Metadata and tags	Re-entered for each copy, or lost	Kept when a new file is uploaded
Links already sent	Still point at the old file	Show the new file
Search results	Every copy appears	One result per asset
History	Guessed from dates and file names	Listed with author, date and note

Anything that points at the asset (collections, share links, portal pages, systems reading it over an API) serves the current version, so a corrected image is updated everywhere at once, including places the team has lost track of.

New version, new asset or rendition

Deciding what a new file is keeps the library clean:

• New version. The same content, corrected or improved: a retouch, a colour correction, a typo fixed in a datasheet, new prices in a sales deck, a logo redrawn during a rebrand.
• New asset. Different content that people need alongside the existing file: another product colour, a new shoot of the same product, a brochure in another language.
• Rendition. A resized or converted copy generated from the current version, such as a web image or a thumbnail. It needs no upload.

What a version history should record

• The version number, and who uploaded it and when.
• A note on what changed and why.
• The file details: format, dimensions, file size.
• A thumbnail, so versions can be compared at a glance.
• Whether the version was restored from an earlier one.

With that record, the history answers practical questions: what did this image look like when the campaign launched, which datasheet did the distributor receive in March, and who replaced the approved photo. Restoring an earlier version should add a new entry instead of deleting the newer ones, so the history stays complete. For a record of every other change to an asset, see audit trail.

Version control in Freedam

• A new version is uploaded from the asset page, with a note describing what changed. Title, description, keywords and the other descriptive metadata stay; previews and AI analysis are regenerated for the new file.
• The version history lists each version with its number, thumbnail, author, date and note, and any earlier version can be downloaded.
• Restoring an earlier version makes its file current as a new version marked "Restored from version N". The file it replaces stays in the history.
• Share links, collections and the brand portal point at the asset, so they show the new file as soon as a version is uploaded.
• Scheduled imports from cloud storage and WebDAV servers add a changed source file as a new version of the same asset during ingestion, instead of creating a duplicate.

Frequently asked questions

What is the difference between a version and a rendition?

A version replaces the asset's file with a revised one. A rendition is a copy derived from the current version, such as a thumbnail or a resized image, and is regenerated when a new version arrives.

Should I upload a new version or a new asset?

Upload a new version when the new file should replace the old one everywhere it is used. Create a new asset when both files are needed at the same time, for example two product colours or two languages.

Can an earlier version be restored?

Yes, in most DAM systems. The earlier file becomes current again, and the file it replaces is kept in the history so the change can be reversed.