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/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:
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.
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.
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.