How to set-up a simple subversion workflow

Question

I am trying to set-up a simple SVN workflow at home. I am new to subversion (and programming) so I have been reading the official PDF documentations but still not sure about how to set-up my repository.

I am working mainly with python, bash and rsl (Renderman Shading Language)

So I already have a /dev structure on my disk as this:

/dev structure

• http://imageshack.us/f/708/devstructure.png/

And I have a /site structure that links to my /dev folder:

enter image description here

• http://imageshack.us/f/651/sitestructure.png/

So obviously starting to use SVN will change this approach that I already have in place.

The question is when I am setting-up my SVN repository for the work I do in my /dev folder:

Will I set-up a separate repository for each different programming platform? and Where exactly I should be placing my repository?

Thanks.

• Hakan Deryal: Just an advice, its worth checking out distributed version control systems (dvcs). The most popular ones are probably git and mercurial. Here you can find the comparison: whygitisbetterthanx.com/#svn
• Michael K: Two things: Git works far better on a local machine than SVN. Second, you might look at unfuddle.com. They'll host SVN for you if you want a more robust backup.
• romaninsh: I've found SVN to be more suitable in a closed development teams, but for personal use Git and www.github.com are great. Read documentation and if you are on a mac, github have a great client app.
• ryanzec: Both Git and Mercurial are free no matter how you run it (SVN is also free no matter how you run it).
• Christopher Creutzig: I don't quite understand the structure you are referring to. Can you make a short description, maybe trimmed down to three or four files, and including what the relation between dev/ and site/ is in the file system. (Better do not write /dev, since that is a standard place on unixoid systems for something else.)

Answer 1

If you new to subversion I would suggestion skipping SVN and moving straight to Git (or Mercurial if you what). Git (and other distributed version control systems) are designed to work a lot better locally and for the most part have everything you would need from something like subversion.

If you do go with git I would highly suggest you learn the command line and GUI tools can only do so much but if you want a good GUI tool (which I use generally for looking at the log/diffs) I would suggest:

Windows

• Git Extensions

Mac

• Source Tree (Free in the Mac App Store)
• GitHubs Mac Client (http://mac.github.com)

Linux

• I have yet to get one to work so you are on your own here

• mbilyanov: Hi, I do not find any of these answers helpful at all. I am asking about a logic that will help me start an efficient repository. How should I set this up in order to be able to work on multiple programming platforms, in a small (almost local dev. environment)? Thanks.
• Kenneth: Use Git... its super simple to get setup and branching is a breeze. Typical branch setups are Master > Dev > Feature. All work is done in Feature branches then merged to Dev. When ready for production merge it to Master and off you go. This platform has worked well for me while working with several developers.
• Kenneth: Also you can do hotfix branches off of any of the branches then merge them back into that branch. And if you want to work independently on several different feature/paths you can branch freely off of the feature branch.
• ajduke: +1 for suggesting git, git rules in source code management !

Answer 2

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 this blog post, which describes a perfect workflow with git.

Answer 3

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.