8

I have several different environments I work in, and several different sets of dot-files I use in each.

Use-Case

Consider the example (simplified scenario). I have 3 environments:

  • work-desktop
  • work-server
  • home-desktop

and I have some dotfiles, which I want to replicate in different environments.

  • .tmuxrc --> work-desktop, work-server, home-desktop
  • .fish/ --> home-desktop
  • .subversion/ --> work-desktop, work-sever
  • A different .zshrc for each of work-desktop, work-sever and home-desktop
  • one .vimrc for work-desktop and work-server, and another .vimrc for home-desktop

Later I might like to change thing so that, I have one .vimrc for everywhere (when I update my homeone to use vundle, and unbreak vim's python compat at work).


Requirements:

  • Must support specifying different files for different environments
  • Must support some files being shared across some environments
  • Must avoid me having to manually copy files and then symlink them back
  • Should commit to version control when triggered
  • Should pull from version control when an update is called.
  • Should support git
  • Would be nice if it supported other version control (like SVN, and Hg)
  • Would be nice if its config file for specifying which files got to which environments took a list of hostnames, but other solutions to the exist.
  • Don't care if it is dependent on anything (A lot of .dotfile management tools i looked at advertised not being dependent on anything but the shell)

  • Must work on all flavours of Linux (but I don't really care about Mac).

  • Must be Free and Open Source.

I hard a close look at RCM, but I am not sure that it meets my version controlling requirements. I also had shorter looks at GNU STOW and Dotbot.

1

There is vcsh which does some crazy magic with multiple git repos that have your home as the working directory, and their git's directories separate. But it seems too complex for my needs, I just keep a git repo somewhere else on my system and manually symlink what I need to it.

The arch linux wiki has a great article on dotfiles.

  • this asnwer doesn't directly repond to whether or not the program meets my listed requirements – Lyndon White May 22 '15 at 0:04
  • I haven't used it, but it seems to me that it would. You would have to organize your dotfiles into different repositories, like it says in the readme. Then you can pick and choose which repos go into which machines. vcsh helps you perform actions on all the repos on one machine, so vcsh pull will update your dotfiles. – spelufo May 22 '15 at 0:18
  • The readme has very little information. The docs make it a little clearer how to use it. – spelufo May 22 '15 at 0:20
  • here on Software Rec SE. we very strongly perfer aswers that come from experience. – Lyndon White May 22 '15 at 0:40
  • Here on the internet we prefer nice people. It's what i've got. If you dont like it move on. – spelufo May 22 '15 at 7:43
0

Why not use simple bash or python scripting? You could have in your VCS one each of home., wdesk. and wserv. variant of each of the .files that you need to control, all in a single directory, and two simple scripts save_env and set_env plus a .env file on each system:

  • set_env would set the .env and overwrite the .files with the env. versions and you would probably wish to trigger a re-read of them with source or the equivalent for the file concerned.
  • save_env would use the .env value to overwrite the appropriate env. files with the current ones. You could then review any changes and commit to your VCS.

Running through your requirements:

  • Will support just about any files that you might need
  • Will support shared files
  • Does avoid 95% of the manual operations
  • Can commit to/pull from VCS if required
  • Could take a list of hostnames
  • Will work on allmost Linux variants should work on Mac as well
  • Free - Open Source if you choose.
  • Flexible
  • Fast
  • Just not pretty and you have to do a little more work setting it up.
  • See requirement 3: Must avoid me having to manually copy files and then symlink them back Building your own is always an option for all most all things, but I would rather not. – Lyndon White Feb 1 '15 at 11:43
  • manually a script doing it for you is not manually - roll your own is usually the best way if you have custom requirements. – Steve Barnes Feb 1 '15 at 14:19
  • you will have to inform the tool where you want what files anyway, so why not put that information in a script? It's about the same amount of work. – spelufo May 21 '15 at 23:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.