Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Versioning Your Home Directory

martinovic.blog

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Versioning Your Home Directory

#31

Post by tomjakubowski »

lionyo wrote: post #29

I use this: https://github.com/holman/dotfiles.git Dotfiles are stored in git, and run a script that creates symlinks to those dotfiles

I do something like this, but I lean on GNU Stow[1] to manage the symlinks.

My ~ directory tree, early on in setting up a new system, might look like:

    ~/
      .config/
      dotfiles/
        i3/
          .config/
            i3/
              config
        zsh/
          .config/
            zshenv.d/
              README.txt
          .zshenv
          .zshrc
When I want to use a package, I cd to ~/dotfiles and run:

    stow zsh
Running that sets up symlinks rooted one directory above, ~. Now ~ looks like:

    ~/
      .config/
        zshenv.d/ -> ../dotfiles/zsh/.config/zshenv.d/
      dotfiles/
        (as earlier)
      .zshenv -> ../dotfiles/zsh/.zshenv
      .zshrc -> ../dotfiles/zsh/.zshrc
Because ~/.config already existed, stow made the zsh symlink inside it. If ~/.config hadn't existed, stow would have symlinked it from ~/dotfiles/zsh.

To remove the symlinks stow set up:

    stow -D zsh
I did eventually set up a wrapper script to pass a few default arguments to stow, to ignore certain files I use for documentation. But stow does all of the work of managing the symlinks.

[1]: https://www.gnu.org/software/stow/manual/stow.html#Introduct...

Re: Versioning Your Home Directory

#32

Post by znpy »

lostapathy wrote: post #28
thwarted wrote: post #10

Earlier quoted context omitted.

There's always zfs send and zfs receive, but these don't work automatically.

The ZFS tools don't really cover the case of ignoring a bunch of transient files in your home directory that you don't want to sync around. Things like browser temp files, etc.

You know, this aspect of versioning a home directory is basically why home directories aren't versioned very often.

That being said, if you want to "version your home directory", I think that zfs is the best approach.

Also, transient files and browser temp files should reside on /tmp AFAIK... So that's less of an issue. If you application is writing temporary files outside of /tmp, then it's probably a bug.

Re: Versioning Your Home Directory

#33

Post by rsync »

Aeolun wrote: post #25
znpy wrote: post #3

That's probably the worst possible way of versioning your home besides, possibly, making a zip of your whole home directory every time you would otherwise to a commit. Just use a snapshot-enabled filesystem. ZFS works awesomely, BTRFS too (but it's not released as stable and production ready AFAIK) and LVM can have snapshots too (take a look at the snapper project by Red Hat). Just use ZFS and snapshot the whole file…

I don’t have ZFS on every PC I work with.

I have absolutely no dog in this fight at all but, in case anyone is interested, if you don't have zfs on a system you can create and maintain "rsync snapshots" by using hard links that take up zero space:

http://www.mikerubel.org/computers/rsync_snapshots/

The idea is, you rsync to a snapshot directory (just like .zfs/snapshot/name_of_snapshot would be) but since you are hardlinking everything, almost all of the files take up zero space. Only files that change get their hardlinks broken and take up any space.

You can put the dir names in rotation and make them work exactly like zfs snapshots.

This is how people did snapshots before zfs.

Re: Versioning Your Home Directory

#34

Post by O_H_E »

znpy wrote: post #3

That's probably the worst possible way of versioning your home besides, possibly, making a zip of your whole home directory every time you would otherwise to a commit. Just use a snapshot-enabled filesystem. ZFS works awesomely, BTRFS too (but it's not released as stable and production ready AFAIK) and LVM can have snapshots too (take a look at the snapper project by Red Hat). Just use ZFS and snapshot the whole file…

Snapper is maintained under openSUSE

https://github.com/openSUSE/snapper

Re: Versioning Your Home Directory

#35

Post by abathur »

It's not perfect, but IMO yadm (https://yadm.io/docs/overview) significantly improves some of the git tedium here.

It's like discovering that there's a special type of hammer just for the task you're doing. You know hammers. You hit lots of things with hammers. The new hammer is a little different, and to be honest you could make do with the old hammer in a pinch, but once you've spent a little time pounding away with the right hammer, you may suspect the world needs more types of hammer.

Re: Versioning Your Home Directory

#38

Post by TopHatCroat »

drexlspivey wrote: post #14

For dotfiles I use the workflow from this comment https://news.ycombinator.com/item?id=11071754 with a keybase encrypted repo I use: git init --bare $HOME/.myconf alias config='/usr/bin/git --git-dir=$HOME/.myconf/ --work-tree=$HOME' config config status.showUntrackedFiles no where my ~/.myconf directory is a git bare repository. Then any file within the home folder can be versioned with normal commands like: config…

This is a pretty great approach, I agree. My version does not offer you a way to easily use multiple repositories.

I will probably have to use this approach at some point as my config continues growing.

Re: Versioning Your Home Directory

#40

Post by matt-snider »

I previously tried configuration management using various techniques. First the plain home git repo, then rcm [1], then briefly stow.

What I found, is that while these systems all worked reasonably well, I ended up writing out several manual steps in README files (e.g. install packages xyz, create user/group, create directory, enable systemd unit, replace {some_template_var} in fileX before copying, etc).

Ansible seemed like a reasonable solution so I switched to that and it's worked out very well for me.

Pros: - all steps can be encoded as config (config-only updates can still be run using tags) - a fresh install can be ready to use in minutes

Cons: - overhead encoding copy operations - slower then alternatives if just updating config (e.g. stow or rcm)

Post reply on HN