Xlinks to single files (VSS style)
We are also interested in the feature that is described here
But linking only single files would be sufficient.
Is it up-to-date that it will not be implemented?
Max Pixel commented
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).
____MNDA/ (xlink to main@contracts/MNDA)
____vendor/ (xlink to main@contracts/vendor)
____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.
____vendor contract.docx (xlink to main@instantiatable)
____MNDA.docx (xlink to main@instantiatable)
____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.