I'm a web developer and I work with various languages and projects (who doesn't?). I've cloned many of these projects/repositories locally to various directories.

Now, with dozens of projects cloned over the years, I feel I'm in a mess as I often need to spend some time to discover where I cloned something.

In short, I need a system to manage local development repositories. The purpose is:

  • better personal organization and
  • faster configuration in case I buy a new machine

The repositories are mostly git, but there are svn and even cvs repos.

Is there a tool that can help me with this? I'd hate to write a custom solution (scripts) only to discover I'm reinventing the wheel.

Are config management tools (chef, puppet, ansible) good fit for this problem?

closed as primarily opinion-based by Celada, cuonglm, Anthon, jasonwryan, slm Apr 30 '15 at 18:27

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • This amounts to pure personal preference of how you like to file things so that you find them. Some people sort by work/personal/play/etc.., others by project name, some people find things by date (based on what era of their life the project comes from!). Some people have a flat home directory with hundreds of files/directories there at the top level, some people don't. – Celada Apr 30 '15 at 15:32
  • This is not an answer, and may not even be helpful, but you could check out the new Kallithea project. It's only at 0.2.1, but growing actively. This is conceptually similar to sites like Github and Bitbucket, but currently has less functionality. To a first approximation it is a web frontend, and currently supports Git and Mercurial. This project has the backing of the Mercurial project, so I expect it will continue to grow and improve. – Faheem Mitha Apr 30 '15 at 16:31

myrepos could be appropriate here; it allows you to manage multiple source code repositories of different types. You can describe all your repositories in a single configuration file, and manage them simultaneously or separately as appropriate.

I don't think a centralised configuration management tool such as Chef or Ansible would be a good fit here...


I keep all third-party sources in /usr/local/src, whether they come from a tarball or some third-party SCM host.

(Why there? Because the default install prefix is /usr/local for most packages, so why not keep the sources alongside the binaries?)

Thus, to set this up a new development machine, I simply say

$ cd /usr/local/src
$ sudo chown $USER .
$ scp -r oldbox:/usr/local/src/* .

When you have multiple active development boxes, this does mean you have to keep schlepping new subtrees over from the last one you used, but I don't find that greatly burdensome.

Sometimes I have multiple versions of a given package, such as the sources unpacked from the last stable release tarball, plus the current SCM "head" checkout. In that case, the tree looks like

 $ cd /usr/local/src
 $ mkdir somepkg
 $ cd somepkg
 $ tar xvf ~/Downloads/somepkg-*tar*
 $ mv somepkg-1.2.3 1.2.3
 $ git pull http://someserver.example.com/somepkg.git
 $ mv somepkg head

That is, I have parallel somepkg/1.2.3 and somepkg/head trees, so I can switch between them as needed. Occasionally I will end up with multiple "stable" versions side-by-side, when I need to use multiple stable versions for some reason.

You might think it would be good to store everything on a local file server instead, but that fails on several levels:

  1. Most file servers run SMB these days; you can't always get the one your want with NFS or another POSIX-compliant network filesystem. That means permissions get screwed up, some legal POSIX file names are disallowed, case insensitivity can bite you, etc.

  2. If you habitually build in-tree (e.g. ./configure && make), you end up with platform-specific autom4te.cache and binary outputs, so you'd have to make clean && ./configure each time you changed boxes.

    You can fix this by always building out-of-tree but not all packages know how to build themselves that way.

  3. Compiling software on a NAS is slow.

Keeping separate copies on each development machine avoids these problems. You do still need to say make clean ; ./configure after scp-ing the checkout trees over to a new box, but having done that once, you now just git pull or svn up to pull the latest changes from the SCM host to get updates, rather than repeatedly scp-ing the new trees over to new boxes.

There are several attempts to create package managers for the web, in order to better solve this: Bower, Jam, npm, NuGet, etc. The problem with these is that you're probably not going to find all of the packages you want to use in any single one of them yet. You're going have to manage sources pulled from some third-party SCM for the forseeable future.