Currently I have a Code directory which is littered with all sorts of stuff and in general is pretty unorganized. Between small code snippets and fully-fledged projects, the whole directory is a complete mess.
Where company or topical are things like 'cloudkick', 'asf' or 'personal'. (I guess you could say, its "who owns the IP").
Some of these subdirectories are actually symlinks to encrypted DMGs, again depending on who owns the IP.
Project is the top level checkout of the projects.. My 'asf' (aka Apache Software Foundation) directory contains 84 project level checkouts.
I also keep a ~/work/temp directory full of random source tarballs if I need to look at how something works. Currently contains glibc, python 2.6 & 3.1, dojo, and about 30 other open source projects, normally ones I'm not normally involved in patching, but often run into... difficulties with. Nothing resolves bad documentation quicker than looking at the source code...
I leave ARCHIVE in all caps because most of my project names are all lowercase, and that keep it from popping up in auto-tab completion. Color me lazy. :)
I do almost the same thing: ~/projects and ~/projects/old
I also have ~/tmp, which is where I put things I'm unlikely to need more than once or twice. Keeps my desktop clear and my projects folder uncluttered.
Each project gets its own folder that contains branches, helper scripts, release files, notes, etc. Nothing related to the project goes outside that folder... except:
Working copies, demo code, samples, etc of dependencies of my projects are kept separate to avoid polluting my backups with stuff that isn't mine.
When learning a new language or framework, I consider it the same as a project and make a corresponding folder. Good to keep learning material, notes, project Euler snippets, etc.
Random snippets, quines that print sierpinski's gasket, and other useless stuff goes into the "Snippets" folder.
Sandbox: Contains code i'm working on or projects that i still consider active. Some of them i've converted to github.
Archived: Contains old projects or code, that are inactive, or somethings that are not on my plate in the near future.
For code snippets you might use gist on github, but i tend to use onenote. I have a queries notebook open on MS Onenote, and anytime i google search some new snippet, troubleshoot advice, configuration detail etc, it goes that notebook, with keyword tags.
Weird, I thought this would be more common, I use:
~/Dropbox/code/<language>/<project name>/
it's all backedup and available immediately on all my machines, pretty handy. sometimes I use git inside of dropbox, but I'm still learning git in a real way so not all of my code is in it.
This is a fun thread to read, I'm starting to question my methods. At the very least seems like there is no reason not to have everything I write inside of git (or some version control).
there was an essay/article going round a few years ago describing how stallman had an entire account on cvs and would simply check it out wherever he was...
One thing I can tell you: I'll NEVER be satisfied with how my code is organised on a hierarchical filesystem (and don't tell me I can simulate a graph properly with symlinks).
I think some sort of tagging filesystem would be appropriate.
Also, I hate how most programming tools assume I want to choose a "canonical" representation of code into files. I'd want to mostly don't care how the code is organized on disk and then write queries which let me view and edit code coming from multiple different files at once.
As a completely hypothetical, contrived example, let's say I was still doing Java and had a big class with many getters and setters, I don't want to choose whether I want the getter and setter of each attribute organised in pairs or whether I want all the getters first and then the setters. I want to be able to write a query that will constitute a new view, so if I want either option I just have to switch views. A third view would simply be the physical representation on disk, which is still needed from and dependencies-loading standpoint. This way of working would truly shine in much more complex scenarios but I hope you see what I mean.
'sandbox' is organised by language, with code snippets and small projects in each folder. If anything becomes of the small projects they migrate to the 'projects' folder. Anything in the projects folder means it must be in a repository, git or svn.
I'm thinking about removing the ${vcs} level though since I've got over 50 projects in 5 different VCS directories and it's getting hard to remember which vcs each one is in.
I have a system that works well for me, basically separating small test/experimental bits of code from code for customer projects. I'll talk about the layout of book code later.
I keep small test/experimental bits of code in sub-directories of top level directories labeled Java_stuff, Lisp_stuff, Scheme_stuff, Ruby_stuff, Python_stuff, etc. Each test/experiment is in a well named sub-directory. These small experiments are useful for both learning and for later reuse on real projects.
I keep each active customer project in a directory with sub-directories for documentation, code, and test data.
For work on books: similar to customer projects: sub-directories for source code, for figure files (OmniGraffle and exported vector PDF files), for code examples, and for Latex (or OpenOffice if I can't use Latex).
I also keep a temp directory for downloading, building, running, and perusing source code for projects that I read about on the web. I periodically delete stuff in temp that is older than a few weeks old.
Finally, not specifically for code: I use Google documents to make copious deployment notes which I use for reference for future projects.
BTW, I also use git for almost all of the materials in the parent comment. I use a very small managed VPS for my git repositories.
For extra backup (in addition to git remote repositories): I have a script that mounts a EBS volume on my always running EC2 instance, does an rsync to the EBS volume of almost everything but decrypted sensitive files, and then unmounts the EBS volume. EBS volumes are reasonably reliable.
I don't keep any snippets around on my machine - just have a knack for remembering how to get to a specific snippet via Google.
Each project gets its own directory that contains everything needed for that project (unless I have a shared framework, library, etc). All the projects are committed to a private SVN repository although I am taking a serious look at Git lately.
By snippets, I mean little bits of useful code or short scripts that I don't use frequently, but find myself reusing them regularly enough to keep them around. Generally, I don't keep these in version control, and as such, they're not posted online.
I might consider moving them all to using gists, but I'm not quite sure if that's ideal.
I have similar habits, which feel like a big time leak. I recommend git because I find the peer to peer model more elegant, but I've yet to use git collaboratively.
"sys" is /etc and other system files from various machines. "web" hearkens to the days when websites were static html and images. Probably should merge that with "src" someday
In src I have some directories such as "hints", "icons", "perl", etc. into which to stuff bits of things that don't deserve their own VCS repository.
I have a directory off the root FS for code I own, a directory off the root for each other IP holder and each person's code goes in their own directory.
currently :
master git repository for everything, something like ~/docs
lots of breakdown of documentation
more git repositories under :
~/docs/code/projects - stuff I am currently working on or using
~/docs/code/legacy_projects - stuff that I don't want to die or need for reference, but I've lost interest for one reason or another
~/docs/code/public_projects - mirrors of servers, portfolio pieces, videos, all sorts of things that other people can see
I've been flirting with mavenizing everything for some time, but I just can't seem to overcome the inertia of... current build process works, code needs to be written, deal with it later
~/dev -- projects I'm (semi-)actively hacking on
~/Repositories -- checkouts of dependencies and projects
I'm tracking but not hacking
~/arc -- same as dev but for work
In ~/p itself I'm putting some .el scripts, .txt, .bat, .sh, .cmd files for various updates (when going to the folder and doing "hg pull", "svn update", "git pull", etc. is not enough).
I have a "Playground" folder with a ton of randomly named projects in it. I like using the word "Playground" because then I don't feel guilty if I don't finish something...
The beauty of a hosted SCM (I use Bit Bucket) is that I only have to remember to "pull" when starting work on a project and "push" when finishing and it is all kept safe :)
I swap between about 4 or 5 machines here and at work so the chances of keeping it sane otherwise are low :)
I use eclipse because it has support for a lot of the different languages I have to work with. So I organize my projects by language first under an eclipse workspace folder.
Then I tend to use the best possible layout for a project of that language. For example since I use CGI::Application a lot using perl, my perl folder uses the following structure:
perl ->
deps/ <-- cpan/other modules that are needed
MyBigProject/ <--Namespace for project modules
startup.pl <- mod_perl2 startup file
templates/ <- HTML::Template templates...
and MyBigProject breaks down like so:
MyBigProject ->
DB/
UI/
(Other Modules)
Was looking for this. I use a ~/workspace/ directory and was wondering where I picked up that notation. Organizing by language is an interesting idea too.
~/projects/PROJECT — my personal projects (no longer used);
~/projects/package-gen/dst/PROJECT — my personal projects in RPM package format, with automatic build system, various templates for new packages, repository of built binary and source packages;
~/work/PROJECT — work;
~/bin — various personal scripts and programs;
~/tmp — scratch, e.g. ~/tmp/1 or ~/tmp/foobar;
~/gtd/projects — various stuff, sorted by purpose, tag or/and date. Links from here to many other places;
~/gtd/income — various stuff, to be sorted;
~/examples — various working snippets;
/usr/share/bash-modules/ - various typical functions for bash scripts, e.g. "backtrace" or "..." (recently created as alternative to ~/examples/bash-..., see http://vlisivka.pp.ua/en/bash_modules ).
I use very simple tagging tool to speedup sorting, e.g. "s foo.tar.gz foo bar" will create two hard links to "foo.tar.gz" file in ~/gtd/projects/foo/ and in ~/gtd/projects/bar/ directories, and so on.
Currently, I use RPM packages only for my own projects, because they are easy to install/uninstall/upgrade, they contains documentation, changelog, and description, they are easy to verify or rebuild, and so on.
Some of these subdirectories are actually symlinks to encrypted DMGs, again depending on who owns the IP.
Project is the top level checkout of the projects.. My 'asf' (aka Apache Software Foundation) directory contains 84 project level checkouts.
I also keep a ~/work/temp directory full of random source tarballs if I need to look at how something works. Currently contains glibc, python 2.6 & 3.1, dojo, and about 30 other open source projects, normally ones I'm not normally involved in patching, but often run into... difficulties with. Nothing resolves bad documentation quicker than looking at the source code...
I tend to nuke temp once every 6 months.