How to arrange my SVN directories?

Question

I have 3 developers in my group, all of them working on the same project which is a .NET VB system. They normally work on different functionalities but often they collide cause they change the same files. Source files are shared on a network device, of course everyone has a working copy (WC) on its own. Question is, what is the best solution on setting the SVN repository? :

1) I import the main source files on the Trunk dir and then checkout on the 3 different WC, each for specific user on their local machine and then handle all conflicts/merge/commit/update from that single Repos. branch.
2) I import the main source files on the Trunk dir, then copy to a single "Branches" dir and then handle all the operations from there. Once everything is set I handle the merge between trunk and branches.
3) I import the main source files on the Trunk dir, then copy to 3 different "Branches" dir like:

svn copy trunk -> branches/user1 ; svn copy trunk -> branches/user2 ; svn copy trunk -> branches/user3

and then handle all the different merging, which I suppose it's a bit complicated.
4) Any other solution ?

Thks a lot.

Answer 1

First off, you said "Source files are shared on a network device". What do you mean by that? For some sites, they have a shared network drive and use file:// to do checkouts and checkins. Don't do that if you're doing that. Use svnserve or Apache HTTPD instead. svnserve is very easy to setup on Windows and directions abound on how to set up svnserve as a Windows service, so it will automatically start itself up and restart itself. The main problem is whether Port 3690 is blocked or not on your network. There are also several Windows packages that will install Apache httpd and Subversion already integrated. Some are completely open source solutions, but most are free.

Occasional file collisions should not be an issue. Subversion is able to handle collisions in a very sane way.. Let's say developer A checks out a working copy and so does developer B. Developer A and B both change foo.vbs. Developer B commits their copy first. When Developer A attempts to commit their changes, Subversion will not allow developer B to commit until developer B updates their working copy to include Developer A's changes. Once developer A does this, and tests their changes, they can commit the combined set of changes. This is your first scenario.

Using scenario #3, by having each developer work on a separate branch really does the same thing as scenario #1: Both Developer A and B create a branch from trunk and checkout from their respective branches. They can commit their work to their own branches without merging, but sooner or later, they'll have to merge their code back to trunk. Then, they'll have the same issue where the first developer can easily do the merge, but the second developer has to handle any merge collisions.

The only difference is when you have to handle merge collisions. Scenario #3 allows developers to ignore the merge collisions until very late in the game which makes handling the merge even more difficult. Scenario #1 forces the developers to handle the issue immediately when the issue is still small. I've had dozens of developers all working on the same branch without any problems.

Answer 2

Sounds like you should adopt the early branching model. Import the main source to trunk, then branch off it and have your team work on that. There may be instances where, during normal development, one person's changes conflict with another, but that is to be expected in any version control system. Be proactive and take it as a learning experience. When you're happy with the work in the branch, merge it back into trunk.

A few pointers:

• trunk is king. Unless you really know what you're doing, trunk should always be in a "golden" state, meaning there should be no commits to it that break the build.
• Name your branches appropriately. Pick a few related development tasks for the week, branch off trunk with a suitable name, work on it, then merge it back at the end of the week. You can then delete the branch and create a new one off trunk, with a new name. Over time, you could tag releases from trunk (v1.0, v1.1, ... etc.).
• Make small commits, with meaningful commit messages. It will help you 3, 6, 12 months down the line.

More information here and here.

Answer 3

I prefer option #3 myself, since it allows each developer to maintain a personal history. Branching and merging are easier the more often they are done, so you may find this workable in the short run. This workflow also maps well to feature branching, which I've come to regard as a best practice.

In the long run, if you plan to expand this team, SVN is a poor fit for this workflow. Consider a DVCS such as Git or Mercurial if you want to work this way, as they greatly simplify branching and merging.