This would be very useful for document repositories. Currently, I have several single-file repositories, one for each document that should be branchable/instantiatable, which ends up being a bit kludgey (but still better than no version control or branching at all).

repos:
documents
documents/contracts (empty)
documents/contracts/MNDA
documents/contracts/vendor

file tree:
contracts/
____MNDA/ (xlink to main@contracts/MNDA)
________MNDA.docx
____vendor/ (xlink to main@contracts/vendor)
________vendor contract.docx
client/Contoso/
____vendor contract for superapp/ (xlink to Contoso@contracts/vendor)
________vendor contract with Contoso for superapp.docx
____MNDA/ (xlink to Contoso@contracts/MNDA)
________MNDA with Contoso.docx

There are a lot of unnecessary folders for single files. If I could xlink a single file, it would be a lot cleaner, and I could have just a single repository for the templates.

Repos:
documents
documents/instantiatable

contracts/
____vendor contract.docx (xlink to main@instantiatable)
____MNDA.docx (xlink to main@instantiatable)
client/Contoso/
____vendor contract with Contoso for superapp.docx (xlink to Contoso@instantiatable)
____MNDA with Contoso.docx (xlink to Contoso@instantiatable)

One thing you can do is as follows:
* Put this file inside a folder, alone, in the original project.
* Xlink to that folder from the other repo.

Makes sense as a temporary workaround?

Sorry for using another account, but new posts will not be persisted for some reasons.

Readonly would be perfect.

We have a project that develops the firmware of a device. In that project are error codes defined in a file. Another project that develops a PC software to communicate with the device. It needs the same error codes. The file with the error codes will always only modified in the firmware project.

Uhm... we closed this for a reason: not enough traction/interest.

What you ask would be *doable* if the shared file is readonly when xlinked, I mean, you can't modify it.

But I bet you want to make it writable, right? Full VSS semantics.

If that's the case: it is simply not doable today for us, because concurrent modifications could end up with merges, and merges require merge tracking, and merge tracking in Plastic is per-changeset, not per-file (like it used to be prior to 4.0), and then... well, simply we can't handle an individual file like that, we need to handle the full tree. The explanation is not straightforward unless you are familiar with how modern DAG-based version controls work.