Software developer, trainer, speaker (Java, JavaScript, Groovy, php, Cloud, DevOps, performance, architecture, motivational topics). I'm a passionate software developer. Software of best quality in the shortest possible time, that's my goal. Thomas has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

Subversion - We don't need no stinking trunk!

01.31.2012
| 4247 views |
  • submit to reddit
Most software developers seem to use a directory called 'trunk' in Subversion. I always wondered what trunk is good for.

In real life software development in a team of, let's say, about 20-30 developers some coordination is needed when making a release version. Often this happens as follows (and I am simplifying):

  1. All developers commit their stuff to the trunk.
  2. The trunk is copied to a release branch, e. g. RB-2.
  3. The new release (with 3) starts on the trunk.
  4. Every developer has to check out the version he needs for further programming, either the trunk for the new release, or the release branch.

Now when a typical developer who is not interested too much in organisational things wants to add an incredibly important, last second change to the release version, he often asks the following question - and I have heard it so often that I decided to write this post:

"Where can I commit my stuff for the current release? On the trunk or...?"
Usually another developer answers slightly irritated: "On the relase branch, of course, we created it yesterday."
- "Ah, sorry, I missed that somehow."

There is a very small idea to improve such a situation (without kicking someone somewhere):
Don't use the word 'trunk' for the trunk, but give it the name of the release branch.

So we might have a few SVN directories like RB-1, RB-2, RB-3.
And everybody knows what stuff goes to which branch.

I admit, for a good developer this idea might sound strange or ridiculuous, but in real life, you know, not everybody is perfect or takes care of all those coordination issues.

Another good idea would be to jump to a more modern system like GIT:-)
But that's a different story.

Published at DZone with permission of its author, Thomas Eichberger.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Senthil Balakrishnan replied on Tue, 2012/01/31 - 12:57pm

Head, Trunk, Main stream are industry standard terminologies. Even though the actual development for a release happens on trunk, IMHO trunk is an unstable code base. Calling it by release name can be far more confusing.

Neil Crow replied on Tue, 2012/01/31 - 1:37pm in response to: Senthil Balakrishnan

I agree, this sounds like a dangerous approach.

It could be much safer to fire the programmers that can't adhere to standard version control practices and hire programmers that can.

Releases should be immutable, i.e. tags instead of branches by convention.

If someone forgot to add something to release 1.1, then it should be added in the next version, i.e. release-1.1.1

Branches and tags have minimal cost in subversion, and can be created daily or even in shorter intervals.

A version should be built, then deployed, then tested and if signed off that same build should be tagged as the release, if not, then increment the version number, apply changes and start again.

Changing the code-base after testing and sign-off in order to save on some version numbers sounds like a recipe for disaster.

But the change was tested I hear the programmer say.
Oh really, where? On your machine?
And how does the change affect the rest of the build, and how is it affected by the rest of the build?

Chuck Dillon replied on Tue, 2012/01/31 - 4:15pm

I'm in agreement with the other commenters.  This situation shouldn't occur.  The paradigm I typically follow is to develop on the main/trunk.  When you think you have a release candidate you freeze changes (i.e. the code), make a snapshot (or tag in CVS) of the RC and proceed to testing.  If a developer wants to make a change after the code is frozen you either say NO or you thaw the release and you don't yet have an RC.

Note that if the team and schedule is complex there could be multiple development branches other than the trunk.  The name isn't what's important.  What's important is knowing properly mapping development branches to development efforts and knowing the difference between a snapshot/tag as opposed to an active branch.  I include maintenance branches in the category of development branches.

In an organzation I recently worked in the trunk was ignored and the team iteratively created branches as the product(s) evolved.  So, if you look at what's in the trunk you see a snapshot of what it looked like somewhere partway through the original development effort.  That team was fine with that method but it made me crazy.

Marko Milicevic replied on Tue, 2012/01/31 - 4:33pm

The group i work with has also ditched "trunk" as an experiment, and so far it has worked out well for us.

In our case we have "version" branches and "release" tags.

eg. Simplified naming...

[project]/versions/V20
[project]/versions/V21
[project]/versions/V22

[project]/release/R20
[project]/release/R20.1
[project]/release/R20.2
[project]/release/R21
[project]/release/R22
...

In this case all development for version V20 of the app remains the V20 branch for all of time.  Release tags are created when the version releases (including point releases).

There is never confusion of where to do dev.  Also there is never a transition where the meaning of a branch changes (as with trunk). 

Another possitive side-effect for us has been merging.  Future versions are branched off of predicesors (V21 is a branch of V20).  This pattern has reduced our merge conflicts, mostly automating a centralized merge process.

One down-side is that it is not conventional.  There is likely other downsides, but we have not hit them yet.

 

Mason Mann replied on Wed, 2012/02/01 - 7:06am in response to: Senthil Balakrishnan

Agreed - trunk is only confusing if you're a confused person.

Thomas Eichberger replied on Wed, 2012/02/01 - 8:49am in response to: Marko Milicevic

Dear Marko, we used a similiar system, it worked fine.


I couldn't express it here well enough, but I was never talking about release tags. I meant release branches which are those branches where developers work for the release. If working is finished a tag is created, and work for the next release starts in a new release branch.

If a bugfix for the previous relase has to be done, one can do it on the previous release branch, because it belongs to that release, and then one can tag again with a new release tag. That means, there might be several tags on one branch.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.