views:

571

answers:

3

How do you organize your personal workspace for your code projects in your home folder? And how do you keep the workspace efficient for handling multiple projects at the same time?


The most important aspect of my question is above. You can stop reading unless you want to address specific subparts of the topic. Below are various related questions about organization of workspaces. No need to address all of them. Interested in hearing even partial answers to some of the following related questions.

This question is mostly in the context of UNIX and OS X. Windows based users can offer suggestions but I am mostly interested in the home folder and command line conventions usually found in UNIX not windows (unless you use cygwin).

In particular what kind of folder structure do you find useful when maintaining multiple code projects at the same time? And when you are downloading a variety of open source code projects how do keep all the various source trees organized without cluttering up your workspace too much?

In particular I am wondering what tricks or tips might have for making the projects easy to access via command line and easy to browse through while getting out of the way when you need to focus on a specific project.

Are there useful conventions you find handy to keep various source repositories orderly? In particular with git how do you keep the different branches and related repositories organized? Do you often blow away working copies and routinely refresh completely from source control? What do you keep around and why? And how do you deal with namespaces and paths if a particular project has a lot of path dependencies that you have to map to your own home folder structure?

What about bin folders and common libraries? How do you manage this if you need to create a lot of potential development environments for various projects (perhaps different versions of PHP, Ruby, Perl, web servers, compilers, etc).

For the seasoned sys admins out there what works from experience and what doesn't work?

How do you keep it as simple as possible but not too simple?

And what gives you the most flexibility to work on multiple projects at once?

Do you routinely move projects out of your workspace and reimport from source control. How do prevent the buildup of cruft while reducing the need to recreate project environments too often?

How do you clean up or blow away your entire workspace so you can start with a blank slate, without losing access to valuable source code and organizational efficiencies gained from past projects?

+2  A: 

I'm not going to answer all your questions; I will say, however, that I use SVN, and I follow their conventions for projects. So I have a folder called:

d:\development

And inside that, all my projects are as sub-folders (maybe 20 or so). In each of them, is

\trunk
\branches
\tags

And that's it. I have a second machine here at home at is my server (and also media center :P), and on it I have SVN running under apache, and also trac, to manage tasks and bugs in each one. Also I have CC.net, for builds.

Noon Silk
+1  A: 

How do you organize your personal workspace for your code projects in your home folder?

As far as UNIXy stuff goes, I place project folders under ~/dev. I'll usually end up checking out something from Subversion into those project folders.

And what gives you the most flexibility to work on multiple projects at once?

For Web projects, maintaining a set of Apache name-based virtual hosts is extremely handy for working on multiple projects simultaneously. http://foo.localhost/ can point to ~/dev/foo/public, http://bar.localhost/ -> ~/dev/bar/public, and so on.

GNU Screen is also key for my local development workflow. If I need to switch gears to another project, I'll just Ctrl-a,c and have a new isolated terminal to use.

David Grant
I have been using MAMP mostly on OS X. But your tip about name virtual hosts makes a lot of sense.
Gordon Potter
+2  A: 

I keep software I've written myself in a special directory, named after my main website - let's call it 'juggle' for the sake of argument. I'd have ~/juggle/software/ inside of which is a subdirectory for each project I write (usually managed with git) and ~/juggle/websites/ under which I have a subdirectory for each website domain, whether raw html or something like webgen or staticmatic.

To help me jump between them, I use 'apparix' which ties into bash quite nicely.

$ cd ~/juggle/software/wolfsbaen
$ bm # bookmarks this with apparix

So now from anywhere I can do this

$ to wolfsbaen

For software I've downloaded, I have ~/software/ and inside that:

  • archives - to keep downloaded source tarballs
  • documentation - for downloaded HTML docs and PDF books
  • hack - for throwaway projects to try new ideas or software libraries
  • projects - for projects I collaborate in, but didn't start myself
  • simple - for bash/python/ruby programs which can run inside their unpacked directories
  • subversions - for all revision-control checkouts: cvs,svn,git,hg etc.
  • unpacked - for unpacked tarballs before I compile them

I also have ~/bin for useful scripts I write and find myself using all the time. I add this to the PATH in ~/.bashrc

I don't think the rest of your questions really apply so well to me; except that with git I pretty much never have to blitz any of my workspace. I make new branches while in the working directory, and stash recent changes if I have to switch branch suddenly. I do also keep a bare repository clone of all my own software and website source:

$ git clone --bare . /srv/git/wolfsbaen.git

I 'git push' to this at the end of every working phase. This makes /srv/git an obvious choice for backing-up.

Cathal
Thanks Cathal. I am digging git. And your workflow here makes a lot of sense to me. And thanks for the "apparix" tip. I was wondering how to do bookmarks in the command line. That answers a question I have been meaning to ask my sys admin friends.
Gordon Potter
Cathal, I've been having trouble setting up Apparix on OS X. Googling brought me to your answer. Would you mind writing a quick guide?
Jonathan Dumaine