* IRC: #vcs-home on irc.oftc.net
-* Mailing list: vcs-home@lists.madduck.net
+* Mailing list: [http://lists.madduck.net/listinfo/vcs-home][vcs-home-list]
-* Pull requests or issues on https://github.com/RichiH/vcsh
+* Pull requests or issues on [https://github.com/RichiH/vcsh][vcsh]
# 2 Introduction #
-vcsh allows you to have several git repositories, all maintaining their working
-trees in $HOME without clobbering each other. That, in turn, means you can have
-one repository per config set (zsh, vim, ssh, etc), picking and choosing which
-configs you want to use on which machine.
-
-vcsh was designed with [mr] [1] in mind so you might want to install that, as
+[vcsh][vcsh] allows you to maintain several git repositories in one single
+directory. They all maintain their working trees without clobbering each other
+or interfering otherwise. By default, all git repositories maintained via
+`vcsh` are stored in <$HOME> but you can override this setting if you want to.
+All that means that you can have one repository per application or application
+family, i.e. `zsh`, `vim`, `ssh`, etc. This, in turn, allows you to clone
+custom sets of configurations onto different machines or even for different
+users; picking and mixing which configurations you want to use where.
+For example, you may not need to have your `mplayer` configuration on a server
+or available to root and you may want to maintain different configuration for
+`ssh` on your personal and your work machines.
+
+`vcsh` was designed with [mr][mr] in mind so you might want to install that, as
well.
-Read INSTALL.md for detailed setup instructions.
+Read <INSTALL.md> and <PACKAGING.md> for instructions specific to your operating
+system.
The following overview will try to give you an idea of the use cases and
-advantages of vcsh. See sections 3 and 4 for detailed instructions and
+advantages of `vcsh`. See sections 3 and 4 for detailed instructions and
examples.
+## 2.1 Talks ##
+
+Some people found it useful to look at slides and videos explaining how `vcsh`
+works.
+They can all be found [on the author's talk page][talks].
+
# 3 Overview
## 3.1 Comparison to Other Solutions ##
Most people who decide to put their dotfiles under version control start with a
-**single repository in $HOME**, adding all their dotfiles (and possibly more)
+single repository in <$HOME>, adding all their dotfiles (and possibly more)
to it. This works, of course, but can become a nuisance as soon as you try to
manage more than one host.
The next logical step is to create single-purpose repositories in, for example,
-~/.dotfiles and to create **symbolic links in $HOME**. This gives you the
+<~/.dotfiles> and to create symbolic links into <$HOME>. This gives you the
flexibility to check out only certain repositories on different hosts. The
downsides of this approach are the necessary manual steps of cloning and
-symlinking the individual repositories. It will probably become a nuisance when
-you try to manage more than two hosts.
+symlinking the individual repositories.
-**vcsh** takes this second approach one step further. It expects
-**single-purpose repositories** and stores them in a hidden directory (similar
-to ~/.dotfiles). However, it does not create symbolic links in $HOME; it puts
-the **actual files right into $HOME**.
+`vcsh` takes this second approach one step further. It expects
+single-purpose repositories and stores them in a hidden directory (similar
+to <~/.dotfiles>). However, it does not create symbolic links in <$HOME>; it
+puts the actual files right into <$HOME>.
-Furthermore, by making use of [mr] [1], it makes it very easy to enable/disable
-and clone a large number of repositories. The use of mr is technically optional
-(see 4.3), but it will be an integral part of the proposed system that follows.
+Furthermore, by making use of [mr][mr], it makes it very easy to enable/disable
+and clone a large number of repositories. The use of `mr` is technically
+optional (see section 4.3), but it will be an integral part of the proposed
+system that follows.
## 3.2 Default Directory Layout ##
### available.d ###
-The files you see in $XDG_CONFIG_HOME/mr/available.d are mr configuration files
+The files you see in $XDG\_CONFIG\_HOME/mr/available.d are mr configuration files
that contain the commands to manage (checkout, update etc.) a single
repository. vcsh repo configs end in .vcsh, git configs end in .git, etc. This
is optional and your preference. For example, this is what a zsh.vcsh
### config.d ###
-$XDG_CONFIG_HOME/mr/available.d contains *all available* repositories. Only
+$XDG\_CONFIG\_HOME/mr/available.d contains *all available* repositories. Only
files/links present in mr/config.d, however, will be used by mr. That means
that in this example, only the zsh, gitconfigs, tmux and vim repositories will
be checked out. A simple `mr update` run in $HOME will clone or update those
[DEFAULT]
jobs = 5
- include = cat $XDG_CONFIG_HOME/mr/config.d/*
+ # Use if your mr does not have vcsh support in mainline, yet
+ include = cat /usr/share/mr/vcsh
+ include = cat ${XDG_CONFIG_HOME:-$HOME/.config}/mr/config.d/*
### repo.d ###
-$XDG_CONFIG_HOME/vcsh/repo.d is the directory where all git repositories which
+$XDG\_CONFIG\_HOME/vcsh/repo.d is the directory where all git repositories which
are under vcsh's control are located. Since their working trees are configured
to be in $HOME, the files contained in those repositories will be put in $HOME
directly.
example: `vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr`
2. Choose your repositories by linking them in config.d (or go with the default
you may have already configured by adding symlinks to git).
-3. Run mr to clone the repositories: `cd; mr update`.
-4. Done.
+3. Make sure the line 'include = cat /usr/share/mr/vcsh' in .mrconfig points
+ to an existing file
+4. Run mr to clone the repositories: `cd; mr update`.
+5. Done.
Hopefully the above could help explain how this approach saves time by
* ~/.gitignore.d
* ~/.mrconfig
-* $XDG_CONFIG_HOME/mr/available.d/mr.vcsh
-* $XDG_CONFIG_HOME/mr/available.d/zsh.vcsh
-* $XDG_CONFIG_HOME/mr/config.d/mr.vcsh
-* $XDG_CONFIG_HOME/vcsh/repo.d/mr.git/
+* $XDG\_CONFIG\_HOME/mr/available.d/mr.vcsh
+* $XDG\_CONFIG\_HOME/mr/available.d/zsh.vcsh
+* $XDG\_CONFIG\_HOME/mr/config.d/mr.vcsh
+* $XDG\_CONFIG\_HOME/vcsh/repo.d/mr.git/
All of the files are part of the template repository, the directory is where
the template will be stored.
apt-get install mr
-#### 4.1.2 Clone the Template ####
+#### 4.1.2 Install vcsh ####
+
+#### 4.1.2.1 Debian ####
+
+If you are using Debian Squeeze, you will need to enable backports
+
+ apt-get install vcsh
+
+#### 4.1.2.2 Arch Linux ####
+
+vcsh is availabe via [AUR](https://aur.archlinux.org/packages.php?ID=54164)
+and further documentation about the use of AUR is available
+[on Arch's wiki](https://wiki.archlinux.org/index.php/Arch_User_Repository).
+
+ cd /var/abs/local/
+ wget https://aur.archlinux.org/packages/vc/vcsh-git/vcsh-git.tar.gz
+ tar xfz vcsh-git.tar.gz
+ cd vcsh-git
+ makepkg -s
+ pacman -U vcsh*.pkg.tar.xz
+#### 4.1.2.3 From source ####
+
+If your version of mr is older than version 1.07, make sure to put
+
+ include = cat /usr/share/mr/vcsh
+
+into your .mrconfig .
+
+ # choose a location for your checkout
+ cd $HOME
mkdir -p ~/work/git
- cd !$
- git clone git://github.com/RichiH/vcsh.git vcsh
+ git clone git://github.com/RichiH/vcsh.git
cd vcsh
- ln -s vcsh /usr/local/bin # or add it to your PATH
+ ln -s vcsh /usr/local/bin # or add it to your PATH
cd
+
+#### 4.1.3 Clone the Template ####
+
vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
-#### 4.1.3 Enable Your Test Repository ####
+#### 4.1.4 Enable Your Test Repository ####
mv ~/.zsh ~/zsh.bak
mv ~/.zshrc ~/zshrc.bak
cd
mr up
-#### 4.1.4 Set Up Your Own Repositories ####
+#### 4.1.5 Set Up Your Own Repositories ####
Now, it's time to edit the template config and fill it with your own remotes:
You're welcome to clone the example repository:
vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
+ # make sure 'include = cat /usr/share/mr/vcsh' points to an exiting file
+ vim .mrconfig
Look around in the clone. It should be reasonably simple to understand. If not,
poke me, RichiH, on Freenode (query) or OFTC (#vcs-home).
~ % cat ~/.mrconfig
[DEFAULT]
+ # adapt /usr/share/mr/vcsh to your system if needed
+ include = cat /usr/share/mr/vcsh
include = cat $XDG_CONFIG_HOME/mr/config.d/*
~ % echo $XDG_CONFIG_HOME
/home/richih/.config
vcsh run $repo git pull;
done
-----------
-
-mr can be found at: [http://kitenet.net/~joey/code/mr/][1]
-[1]: http://kitenet.net/~joey/code/mr/ (http://kitenet.net/~joey/code/mr/)
+[mr]: http://kitenet.net/~joey/code/mr/
+[talks]: http://richardhartmann.de/talks/
+[vcsh]: https://github.com/RichiH/vcsh
+[vcs-home-list]: http://lists.madduck.net/listinfo/vcs-home
projects / code / vcsh.git / blobdiff