The file you're opening — is anyone else in it?
FileES keeps a team's binary work — .psd .blend .obj — in sync
on top of version control, with real reservations for editing, so two people
never overwrite each other's work. No conflicts, no merging: the files we
use most were never mergeable to begin with.
ACCESS No hidden
cookies No
tracking Clear
contracts Toolchain,
not system
Cloud sync doesn't know your file can't merge.
An .html or .txt file can be merged.
A 400 MB .pln file cannot. When two people save the same document,
Dropbox, Nextcloud and Drive don't warn anyone — they just quietly write a second
copy and let you find out after the fact.
So distributed teams invent their own safeguards: a name in the file name. A Slack or Signal message. A sticky note on a monitor. A kick in the shin under the desk… It works. Until it doesn't.
Sign it out.
Work on it.
Check it back in.
A reservation blocks parallel editing of the same document: only one set of hands on the original at a time.
- 01A background watcher notices the file is open and reserves it — no dialog, no setup.
- 02The lease renews itself while you're active, and expires on its own if you go quiet.
- 03Every teammate's desktop app sees the same state immediately — before anyone opens the file.
- 04Published changes go to Subversion on the server in the background, so every revision is real history, not a folder full of guesses.
| Type | Format | Notes |
|---|---|---|
| 3D scenes | .blend .fbx | Reserved on open, released on save-and-close. The lock always expires on its own when its lease runs out — nothing to click. |
| Raster art | .psd .ai | Full revision history on the server, the latest state on your disk. |
| Geometry / CAD | .obj .dwg | Reservation rules as in a library: borrow — work — return. |
| Layouts | .indd | Watched patterns are configured per document set, not hardcoded into the app. |
Ordinary folders, not a VCS to operate
SVN semantics stay hidden. You work on plain files in your own folders; the desktop app keeps them in sync with the server — SVN is durable storage and history, not a new interface to learn.
Large binary files are the default case
CAD, graphics, 3D, multimedia — the point, not an exception. Large files get their own steady publishing flow and never block ordinary sync with the server.
Locks for files that can't be merged
Reservation state shows up directly in the interface. Lock, unlock, and — where a team needs it — an administered checkout model, not a “safe” naming convention.
Share, join, and browse — without touching SVN
A public link opens no access to your storage; it serves only what a realm member chose to share. Newly activated workstations create their own realm or join an existing one, and attach locally only the folders they need. The Android app fetches material from the realm and uploads its own — an assistant, not a workstation.
Server services under your control
The background service owns state, recovery and policy; the interface only collects intent and shows state — its crash never stops sync. As part of its core functionality, FileES does not start resident server processes without your decision. Optional services, such as public link sharing, may require them.
Ransomware can encrypt your data today. It can't rewrite “yesterday”.
A compromised workstation can encrypt your files and even publish those encrypted versions to the server. It still cannot rewrite repository history from the client app. Every published version stays visible and recoverable, all the way back to the moment the repository was created. The “Time machine” shows your folders at any point in their history and lets you download copies of saved states to a new location — without touching your “live” working copies.
See the time machine in the demo →Full architecture, trust boundaries and authority rules: manual.filees.space →
