Thanks you each for your one line of encouragement. I take it you are busy people.
I’m not sure what, if anything, you are asking me to do.
I think syncthing is an interesting piece of software that syncs files very well
but I’m not sure if you want it to be a system tool or an application for friendly users (or both).
Which use cases you want to support has a bearing on what I might propose and whether it would be worth while.
syncthing isn’t a backup tool and it isn’t git and drawing analogies with them only takes you so far. I think syncthing has a symmetry that backup programs and git don’t have and I believe it merits an inclusion/exclusion mechanism that reflects this.
Use Case: I’m Not A PC
For my first trial I tried the default: sync everything. This probably works very well with the defaults on most PCs and mobile devices.
For me, syncthing got stuck. I learnt that I’d been doing backups relying on read access only for years but that syncthing insists on read and write access to files (at both ends). Symmetry.
For me, a system tool should not require me to reorganise my file systems in order to use it.
I should be able to configure it to work with what exists and take a view on how to follow up.
The ‘ignore’ feature was the only way forward. I have cases where it was easier to say what to include rather than what to exclude but the current include syntax is clumsy.
I can imagine easier ways to handle files can’t be synced.
Use Case: Projects on a File Server
This is Cathryne’s use case. One sync folder on a file server and client PCs that sync only those projects their owner’s want.
This is a use case I can easy see myself wanting to use.
The current syncthing alternative would be to set up a sync folder for each project. That would seem to me to imply a lot more of Cathryne’s time taken up in administration.
Use Case: The All You Can Eat Buffet
I had a brief encounter with bitsync. The sync was very badly set up. This wasn’t the tools fault. The project manager’s view was it only needed a few clicks to set up. What could possibly be wrong with that ?
The sync was used to distribute (development) releases. Each release was another subdirectory and there was a release every other week. Each release was the order of 5 Gb.
What a waste resources.
It was a waste of time too: someone new to the project had to wait while all the releases synced
because there was no way to prioritise the synchronisation of the most recent release.
The general point here is that, when joining a large, existing sync, it is a lot easier to list the things you do want than it is to list all the things you don’t want (and may not know or care about).
Use Case: Divide and Conquer
This use case is mine but is it similar to Cathryne’s but there is a twist.
I have a file system with ‘projects’, just as Cathryn does, but I have ‘projects’ within ‘projects’, as it were. Hence the tedious syntax illustrated in my earlier contribution.
Roughly everyone has read access to everything … there are no secrets
… but only one person has write access … different people are responsible for different ‘projects’.
Currently that would mean a separate instance of syncthing for each user … OK … which means a sync folder for each user … oh dear …
With the current ‘ignore’ scheme each user needs a different set of rules but there can be only one .stignore file in the root directory of the file system.
syncthing is not git
Committing files in git is a way of backing up files. Pushing and pulling git repositories is synchronising backups.
It’s not syncthing. It’s not even close.
The .gitignore file (as the documentation says) is about ignoring ‘untracked’ files. It has no effect on which files are pushed or pulled and it does stop you committing files that are ‘ignored’ if that is what you really need to do. It just makes it easy not to commit files that have not been, and never should be, committed.
The patterns in .stignore represent not just files that should not be synced ‘to’ other devices
but also files that should not be synced ‘from’ other devices. Scary and intriguing.
Where am I going with this ?
I think inclusion and exclusion should be on an equal footing:
the current ignore with the ! syntax is unequal.
A simple analogy might the hosts.allow and hosts.deny mechanism on Unix systems. If you don’t know or like this analogy, pick any firewall you are familiar with.
You can start with “allow everything” and add a few exclusion rules. You can end with “exclude everything” and insert a few inclusion rules. You can do anything in between.
Perhaps such a scheme would require too much testing.
Assuming that it is something you might consider, the first task would be choosing a syntax that might allow enhancements to be added later. The ! syntax is no good.
At present, if two devices have different .stignore files then one or other will never achieve 100%
synchronisation. Very disconcerting. The more devices in the sync, the more disconcerting.
With the right syntax to start with, an enhancement might be new syntax that means ‘when device equals’. This would allow the rules to be tweaked until 100% synchronisation is achieved with each device.
Another enhancement might be syntax that means ‘when user equals’. This would allow rules in the same file for different instances of syncthing running under different user ids but with the same sync folder.
There might be, at some time, a case to be made for distinguishing ‘in’ rules from ‘out’ rules.
The ‘everything else’ rule might be an example: sync everything else ‘out’ but nothing else ‘in’.