How to set up work space (directories) for software development:


How to lay out a work space for software development:

Q: Why not use
/Users/yourNameHere/blah.blah – everything in the login directory?

A:Its messy, impractical hard to export.

Requirements for a software development workspace:

  1. Makes it easiest to do things the ‘right’ (you choose ‘right’) way.
  2. Source files and support stuff can easily be version-controlled: using a third party tool (Perforce, etc) or informal methods (numbered revisions in a “History” or “Rathole” or per-file subdirectory below the working directory, etc.
  3. Environment neutral: Easily exported to someone else’s environment (Some people don’t value this- I like to send out examples that arrive workable and sometimes I ask others for help. If you don’t need that, by all means have a big alias file and a bunch of stuff in /bash_profile… But do consider packaging all of that stuff so you, yourself, can move from system to system, OS to OS…)
  4. Scalability: One file, 100 files, 100,000 files (i.e, no bottom)

I’ve seen a bunch of somewhat thoughtlessly assembled setups at a variety of work environments. Back in the mists of time, at Lomac, in 1979, we didn’t have password protection on our 8 inch floppy environments (RT-11 for PDP-11/03, and CP/M for S-100 Z-80s). Easy stuff. Boot up and, on a build disk, there it all was. (WERE there subdirectories in RT-11 and CP/M?, Google knows…)

At Perforce, the Performance Lab used a nice organization of:

/Users/yourNameHere/- anything and everything, but no production stuff here.

Installed stuff, supported by two additions to PATH

export PATH=$PATH:/Release/namedRelease_*:/Work/yourNameHere/namedRelease_*:.

This then became:
/Releases/namedRelease_1/usualTopLevel
/Releases/namedRelease_1/usualTopLevel/bin
/Releases/namedRelease_1/usualTopLevel/etc
/Releases/namedRelease_1/bin
/Releases/namedRelease_2/usualTopLevel
/Releases/namedRelease_2/usualTopLevel/bin
/Releases/namedRelease_2/usualTopLevel/etc
/Releases/namedRelease_2/bin

Database location:
/db/namedRelease_1/
/db/namedRelease_2/

Leading with a named release allows Path to mix and match generically named 3rd party tools. Like Source Control Management…

Project work:
/Work/yourNameHere/namedRelease_1/
/Work/yourNameHere/namedRelease_2/

and if you absolutely, positively, have to work in /Users…
/Users/yourNameHere/namedRelease_1a
/Users/yourNameHere/namedRelease_3b

What NOT to do:

The “namedRelease_*” paths looks unnecessary, up to the time you need to maintain two parallel developments. You can keep one in /Releases/usualTopLevel/… and one in /Users/yourNameHere/usualTopLevel but its all too easy to get to:
/Releases/usualTopLevel/…
/Releases_1/usualTopLevel/…
/Releases/usualTopLevel_2/…
/Users/yourNameHere/usualTopLevel/…
/Users/yourNameHere/usualTopLevel_A/…
/Users/yourNameHere_2/usualTopLevel/…

and having to hand edit these irregular paths here, there and everywhere. Ask me how I know. 🙂

And what I plan to do here at home:

/Work/Bill4/rel_1/
to start with. Its pretty light weight. just took a few minutes to set up.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s