1

I have recently started a new job and up to now they have only had one developer. Using Eclipse and Collabnet with Subversion. So, he hasn't had any problems with clashes etc. Even more so because it is a complete re-write of an original application so there is no clash with any other code.

This also enabled him to commit whenever he wanted (just in case his computer "died" on him) without any problems.

The SVN directory was built without a trunk. Everything is directly in the root directory.

We now have 3 developers. I still want to enable them to commit daily but not to interfere with each-others' work. So, I assume the correct way is now to create a trunk and then a separate brank for each developer. Is that correct?

If so, what is the easiest way to do this change. I saw this link but it is very old and I am wondering if there is a new, easier way to go. Is there a clean way to move / to /trunk?

Community
  • 1
  • 1
theblitz
  • 6,683
  • 16
  • 60
  • 114

2 Answers2

2

Commit and update often.

Conflicts have to happen unless different sections of code are being authored/edited. The earlier the conflicts are encountered (and thus the smaller they are), the better. Committing daily is not nearly enough.

Commits should ideally be atomic changes. The smallest possible change that adds something to the code while maintaining stability and correctness. In other words, if you're adding 3 different features and then committing, the commits are likely not small enough. Each feature should have its own commit. (Or, if any of the features are not small, likely more than one commit.)

Ideally you should also try to communicate what will be going through changes. How well it works in practice varies a lot, but if you know that programmer A is going to be working on module X today, then it might be a good idea to avoid modifying module X code unless necessary.

As for moving the root, that is indeed still the recommended method as far as I know. Shouldn't be a big deal to just do it once.

Edit: I should probably mention that I'm by no means an svn-workflow expert. I've worked on a 4 person team using git for about 6 months, and a 2 person team using svn for a few years. This post is based on things I've noticed have helped or hurt us over time.

Corbin
  • 33,060
  • 6
  • 68
  • 78
  • We can't commit a partially finished item. The code might not even be working yet but the developer wants to commit so that the code is now in a safer place since the workstations don't have any backup and the SVN server does. – theblitz Jun 07 '12 at 07:19
  • @theblitz Depending on what partially finished means, partially finished things should usually not be committed. Each revision should ideally represent a meaningful software revision. What I meant with the large feature note was really aimed more towards features that are logically 1 feature as far as a client is concerned, but more than one part in terms of code (for example, a complex searching page could have a base searching page committed and then a more advanced searching page later committed). – Corbin Jun 07 '12 at 07:22
  • If a dev is using svn for backup, that likely means that he's holding onto code for too long. If it's due to pace of work, there's not really a pleasant solution. If it's due to commits that are too broad though, that can usually be remedied. You may have to choose between convenience and repo cleanness. For example, if a dev is only 1/4 of the way finished with something, but it's 5 on Friday, that leaves a tough choice in terms of committing if data stability on work stations is in question. – Corbin Jun 07 '12 at 07:23
  • Generally it is not a problem since things don't usually take more than a day or so. However, when we are building new sections or making big changes then problems can arise. Commiting unfinished (and maybe even non-compilable) code would cause problems for others if they were to "update" from SVN any code. – theblitz Jun 07 '12 at 07:37
  • 1
    Ah big new sections are often when branches come into play. The advantage of branching is that you get to isolate a branch of code from trunk, and thus it can be as stable or unstable as you want while maintaining trunk's relative stability. Then once the branch has served it's purpose (unless it's meant to be an always existing branch), it can be merged back into trunk. The disadvantage of branching though is that depending on how far from trunk the branch has become, merging may be extremely painful (though it's often unavoidable). – Corbin Jun 07 '12 at 07:40
  • 1
    Maybe take this opportunity to move away from Subversion which is fairly brain-damaged, and use something decent like Mercurial or Git, which allow developer-local commits and really easy merging. – artbristol Jun 07 '12 at 08:07
  • Thing is that Subversion comes with a purpose-built interface with Collabnet – theblitz Jun 07 '12 at 13:57
1

Branching should not be necessary your the day-to-day work. Just have everyone work on the files in the main source directory. It may be clever to move the code to a subdirectory (for example "/trunk") so that you can have other directories in the root as well (a directory for branches for example).

Conflicts will happen when you develop, but they should be small and easily resolved. Commits should be as small as possible. TortoiseSVN has a good user interface for resolving conflicts when you commit.

The only time you must use a branch is if two or more developers work together on a feature that cannot be committed to the trunk, for example if it is not ready to be released in the upcoming release and is scheduled for a later release.

A good time to create a branch is when you release your application. Create a branch called 1.X for the first release. Then continue working towards 2.0 in the trunk. In the 1.X branch you can build a 1.0 release, and also later a 1.1 release and so on (without disturbing the work towards 2.0 in the trunk).

Note the difference between these two types of branches: the release branches are forked from the trunk and live forever. Individual bugfixes can be merged between the trunk and a release branch, but the release branch is never merged back into the trunk.

In the feature branch, trunk changes are continously imported by merging. When the feature is complete, the entire branch is merged into the trunk, and the branch isn't used after that.

Release branches            __testing_1.X__..._rel_1.0___.._rel_1.1    ___2.X_branch_
                           /                                          /
___________trunk__________/_______trunk______________________________/____..
      \                                               /
       \_____really big feature for v2 only__________/ 

Feature branches

For day-to-day development you can use branching as much as you want. One option is one-branch-per-feature, but you will probably find that this creates more problems than it solves for a small team. Resolving conflicts in SVN is usually much easier than managing several branches and performing many merges. In other version control systems (for example Git) the situation is different.

Anders Forsgren
  • 10,827
  • 4
  • 40
  • 77