How to set-up a simple subversion workflow

Where to put files, directory structure etc. doesn't have anything to do with version control systems. Whether you use svn or git, they all keep track of the files you want in some way. If you want to learn about how to structure your files, directories etc, it's entirely a different question. If you want to learn an efficent way to use version control systems, I suggest you to check http://nvie.com/posts/a-successful-git-branching-model/, which describes a perfect workflow with git.

Ignoring all biases towards one or another VCS, the layout of your dev directories should conform to what works best for you while working. Then you map the version control to that. One (lazy) pattern is just to host the VCS at the top level (/dev) and let everything be part of one big repo. I don't like this, and it's probably a bad idea anyway. Ties too much stuff together (and yay, this is how my office uses TFS). A better idea is to split along either project lines or conceptual lines. A conceptual split in your case would be to put all the bash projects into one repo. Another similar idea is to put all projects related to one larger goal into a repo together. A project split would be to put each individual project as its own repo. I like the project split best myself, as I think this gives you the most granularity in maintaining the repo, and it keeps the history clean by only showing one project. Obviously some VCS will favor different splits, and offer varying support for them. In SVN in particular, it is very common to have something like: /ProjectX (RepoRoot) | |--/trunk | |--/ProjectX |--/branch | |--/ProjectX_401changes | |--/ProjectX_refactoring | |--/ProjectX_failedExperiment |--/tag | |--/ProjectX_Release20120101 | |--/ProjectX_Release20120411 Again, most VCS programs will have their own ideas about how that actually looks, but pretty much all of them offer something like this conceptual divide. They key is that not only is your code versioned through changes, but also release states. Code can be the main line of development (Trunk), an offshoot to add complex new features or to experiment (a Branch), or a known good state that you should be able to easily get back to (a Tag). Generally you'd host the "central" repo on another machine, but you can also just use another folder on your computer (but preferably on a different harddrive at the very least). If you have multiple repos, then you'd probably roughly mirror your working pattern, but with the SVN structure above in each repo folder. Note that in reality, the remote repo is often called "bare" or something similar because it doesn't actually have a copy of the real files exposed, it just hides everything inside the .svn folder (or .git, .bzr, etc). Finally, using any VCS means learning the tools. You can use a graphical tool if available, and they tend to make using VCS a lot more pleasant. However, the command line tools are usually quite easy and will help you understand what VCS is actually doing. You typically need 3 basic commands for daily work: download (get changes from repo), upload (put changes into the repo), and status (what changes do I have). In SVN, these are: svn update (download) svn commit (upload) svn status (status) Other commands are less used, so you won't have to be as intimately familiar with them. Typically the additional ones you need to get started are: add, create repo, and create local copy. In SVN: svn checkout (create local repo) svn add (add files to the repo) svn create (create a repository, ie on the server) Other VCS will have some extra commands you need to know. Git, Mercurial, Bazaar, and other distributed systems usually have a distinction between local commit and remote commit. In most of them (git and bazaar as I recall, at the least) the command to locally commit is commit and the command to push your changes up to the remote system is push intuitively enough. Pull is used to get changes instead of update.