doekman / config-man Goto Github PK

Well actually, there is always some kind of configuration. But in this case, the backed up files itself is the configuration. For example, you want to backup the following files:

/Users/me/.ssh/config
/Users/me/.gitconfig
/Users/me/.gitignore_global

and assume the backup location to be /Users/me/config-man/vault. So if you want to keep backups of the three files above, create the following files:

/Users/me/config-man/vault/Users/me/.ssh/config
/Users/me/config-man/vault/Users/me/.gitconfig
/Users/me/config-man/vault/Users/me/.gitignore_global

Above files is the configuration. The files may be empty, or just be a copy of the original. When the file exists, it will be included in the backup. When a file doesn't exist, it will be made empty (and generate a warning), but the file itself won't be removed.

Looks pretty crazy, right? But bear with me; it does have a lot of advantages to organise the backup vault like this:

1. It is very transparent: you directly see what files are backed up. Not only contents, but also name and location.
2. Once you created this file tree, you only need to run the (yet to be created) cm backup command to update the files when some have changed
3. This vault is also easily made accessible via git or Dropbox.
   • With git you could create an "audit trail" of your configuration. Or you could think of it as configuration as code. This will be very handy when investigating an issue.
   • Dropbox could come into use when you have multiple machines, and you want to compare settings.
4. One could also make a plain shell script just copying these files: but in that case it would be more difficult to create cm restore or cm compare commands. And you would mix data and program. Config-man is about separating these.

There also are some limitations about above proposition. I think most of them can and will be addressed in the future. However, two thing come to mind that would be needed for creating a Minimal Viable Usable Product.

1. Creating the vault-files is cumbersome. The touch-command would create an empty file, but doesn't create the folder-structure. And mkdir -p ... will create the folder-structure, but doesn't create the actual file. So the sensible thing to do is to have the cm add FILE command initially, and make that do the work.

2. Running the cm backup command from the "wrong" folder most times would result into a no-operation. In some situations it could have undesireable results. On the other hand: specifying the path to the vault on the command line is also cumbersome. Placing a "marker" on the root of the backup vault (or backup base) would solve this problem. Using a file with the name .config-man would act like a marker. The cm commands need to be ran from within this folder. For now, the file itself can be empty. It will be specified in json format. Also: this file will be excluded from the backed up files (it also makes no sense to have a file called .config-man in the root of your file system, let alone to have it backed up).