On Wednesday, 2014-02-19, 17:42:37, Richard Hartmann wrote: > On Wed, Feb 19, 2014 at 1:40 PM, Simon McVittie
> > But > > surely if it's small, it doesn't matter if it gets sync'd across > > machines unnecessarily? If an application wants to store explicitly > > per-machine state, it can use the D-Bus/systemd machine ID as a key, > > like GNOME does for display settings (I know that's config rather than > > state, but the principle is the same). > > Thanks for this; it highlights precisely why state is needed. > > This is not about storage size, it is about churn in configuration files. > > Looking at, e.g., geeqie, there's a section called <layout> in > geeqierc.xml. This contains window size, last path, and a plethora of > stuff configuration management does not care about. > > Assuming you put your configuration under proper version control, this > state information changes all the time. It is not something you want > to sync between machines for several reasons. You are synching state > information which may be invalid (lastpath), non-applicable (desktop > resolution settings on a netbook), or outright harmful (this directory > is not needed any more). Additionally, you are filling your VCS > history with random noise, making tracking the actual changes harder. > This results in broken workflows, manual rewriting/pruning of state, > or outright breakage. > > And _that_ is why Thomas, me, and others consider carrying state in > configuration such an issue. So it is mostly about developers using the same file for config and state instead of using a separete state file? If it where in a different file, even in the same location, then only the actual config file would be tracked by the VCS and the state files would not. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
