Wiki

Distribution

Copy files (plugins, shared content) from a source repository to a target repository by path patterns. Publishing, remapping, locks skipped.

Introduction

Distribution copies files (a plugin, a shared content pack) from a source repository to a target repository, limited to a set of path patterns. It creates new revisions in the target, so the usual incremental synchronization propagates the content to clients. It is the way to share the same plugin across several projects without manual copy and paste.

Access and roles

An access model different from the other tabs Distribution is not gated like the other tabs. It requires the manage_rules capability, held by admin and lead, across the entire server. A project_admin, which holds no capability, does not have access. A lead, on the other hand, can link any repository to any other.

Create a link

The New Link form: Source Repository, Target Repository, and the Path Patterns area.

Distribution tab → New Link.
Source Repository: the repository the files come from.
Target Repository: the destination repository (the chosen source is removed from the list; source and target cannot be the same).
Path Patterns: one pattern per line (e.g. Plugins/MyPlugin/, Content/SharedAssets/). At least one is required.
Confirm with Create Link.

A link that already exists between the same two repositories is refused (conflict). Each row shows source → cible, its patterns, who created it and the date of the last publication.

Path patterns

A pattern matches a path if it appears anywhere in it (a "contains" style search). So a Plugins/uVersion pattern matches DefaultProject/Plugins/uVersion/Source/Foo.cpp regardless of the project prefix. The trailing slash changes nothing.

Publishing

The pending files list (new/modified/locked) and the publication summary banner.

Three actions on each link:

Show pending files (file icon): lists the files that differ, marked new, modified or locked, with their revision.
Publish history (clock): the last 50 publications (how many updated / skipped, who, when).
Publish (send): runs the copy. A banner summarizes "X source files found, Y updated, Z skipped (locked), W unchanged". Disabled if the link is inactive.

A file that is locked in the target is skipped, not overwritten. A file whose content is identical (same hash) is counted as unchanged and skipped. Publishing is atomic (a single transaction).

You can also enable / disable or delete a link.

Remapping and revisions

The path is rewritten for the target: uVersion strips whatever precedes the pattern that matched, then adds the prefix detected on the target. Example: source DefaultProject/Plugins/uVersion/foo.cpp, pattern Plugins/uVersion, target prefix CineDroneStudio/ → CineDroneStudio/Plugins/uVersion/foo.cpp. The target prefix is inferred from an existing file in the target (handling repositories with or without a project subfolder).

Revision numbering Distributed revisions use a global counter above the target's current revision, so that incremental sync picks them up. A file's history can therefore "jump" (e.g. rev 1 then rev 200): this is cosmetic. Chunks are shared (no data duplication, just a reference increment).

Common pitfalls

"Publish" is greyed out

The link is inactive. Enable it first. Publishing an inactive link returns an explicit error.

A file is not updated in the target

Either it is locked on the target side (it is then skipped and counted as "locked"), or its content is already identical (counted as "unchanged"). Check the publication summary and the pending files list.

A project_admin does not see the tab

This is intended: distribution requires manage_rules (admin or lead). A project_admin has no access, even on its own repositories.