Version 0.8.10 brings “Simple File Versioning”. It can be enabled among the repo settings:
When enabled, each time syncthing replaces or deletes a file the old version will be moved into a directory called .stversions in the same directory as the file. The file name will have a date stamp (YYYYmmdd-HHMMSS) appended to it. Only the latest N versions are kept, with N being the value set in the config.
Given a file repoRoot/foo/bar to be replaced, it would be moved to repoRoot/foo/.stversions/bar~20140525-211000. If there were already N versions of bar in .stversions, the oldest would be removed.
The .stversions directory will not be synced to other nodes.
Note that versioning does not apply to changes you make to files locally. Versioning only applies to changes done by syncthing as a result of changes announced by other nodes.
If this versioning scheme does not fulfill your needs (needs vary, and it will certainly not suit everyone), you are able to implement your own (given some knowledge of programming in Go):
I’ll let the guiding principle here be to avoid surprises as far as possible. Creating new directories and files and stuff all over the place is more surprising than not doing it, unless it was asked for explicitly.
My opinion: It’s better to create backups than to loose something. We have a protection in the case:
The user accidentally deleted something.
syncthing has a bug.
IMHO safety fist: Enable file versioning by default. Experts can simply disable it if needed.
Why we have everywhere a Trash for deleted files by default?
It’s debatable in either direction and boils down to opinion. In this case, the default stays off. It’s anyway not something that should be changed in a patch release (even introducing the feature is borderline, but hey, 0.x!).
IMO the name of the option is a bit misleading (at least for the casual user). “Simple versioning” implies that there is a non-simple versioning which is going on by default, and which is somehow simplified by turning this option on. At least it should be clarified that by default there is no file versioning whatsoever. Perhaps drop “simple” from the name altogether.
Merged. For the record I found it non-confusing (but then again I wrote it) and the reason for the “Simple” prefix is that I envision there fairly soon being other variants. But there’s not point in preparing that which doesn’t need preparing, and when that time comes the widget will be something like a radio button selecting between “No Versioning” / “Simple File Versioning” / “Super Duper Versioning” etc.
