SourceForge review

Since I picked GPLV3, as OSI approved Open Source licence, it opened up the popular SourceForge platform as a host for my CloudPad application.

For developers not familiar with SourceForge it provides cloud based tools that allow a developer or team of developers to host their Source Control repository, manage the development team, interact with users, provide a news feed and release software.

I have not been using the system long so am still finding my way around. There are a huge number of tools available but as I have not explored many I will just give a quick overview of what I consider the vital ones.

Source Control

SourceForge provides hosting for a number of Source Control systems. The ever popular Subversion, The new kid on the block Git, the aging CVS along with some others I have not heard before.

Being familiar and happy with Subversion it was a simple choice to pick that although I hear good things on Git. Avoid CVS though unless you have a pressing need for it as it really is showing its age.

By default there is public read access to the repository and write access for the account holder of the login that created the SourceForge account. As you add developers to the project they are given access to the repository.

File Hosting and Release

There is a file hosting and release system that allows you to make your application setup files available to people. It groups files by application, version and platform so it is easy for users to locate the latest version for their system. Once you have files uploaded they are accessible from the Download button on your projects main page.

Bug and Feature Request Tracking

There are a number of tools that provide for bug and feature requests. I selected MantisBT as it appeared to be feature rich and well supported.

If you have ever used a bug tracking system you will feel right at home as most of the good ones I have used feel similar once you get past the different looks, Mantis is no different. It provides all the normal reporting, tracking, assigning and logging feature. It will even produce change logs for you application based on the state of the “tickets” in the system.

Project Forum and Wiki

Not much to say about forums and Wikis, they are a common part of the Internet and need no introduction.

Other

There are a load of other features I have not even touched on yet so here is a quick list of some.

• Screen shot hosting.
• Project activity log.
• Mailing lists.
• Automatic backup.
• Help wanted advertising.
• Documentation management.
• Blogging.

The final point of interest is Donation management so people can donate money to the project, one of the few forms of revenue open to Open Source projects.

What does all of this cost you….. $0. Yep its all free!

If you are planning on releasing you code as an Open Source project you should take a long look at SourceForge. It is one of the longest running and most popular systems in this area for good reason

Subversion Commandments

Today at work I noticed another developer, who had been working on the current release branch of our main product managed to completely f**k up the repository and kill the revision history on the main project file. The result is the disconnect of 4 years of revision changes on the project file.

I tried everything possible to recover and reconnect the history but everything fails because of the strange state of the file in question. Things such as doing of copy of the file from a good version into head fail to work. The change history on the file is VERY strange.

r10000
D file

r9999
A file

r9998
M file

How he managed to add a file that already existed at a given location then delete it while leaving it in the repository is beyond me.

The net result is the same as the file being deleted at R9999 then a new unrelated file being added at R10000 but that does not let you have access to the file in r9998 via @.

4 hours of trying to solve the issue resulted in FAIL. The final attempt would have been branch at r9998 and make that the working branch then delete the bad branch. This could not be done as we have enough changes committed and also in the pipe in working copies that made this a large a logistic issue.

Apart from this issue the repository appears fine so we will have to live with this and move on, at least the history is still accessible from the main trunk .

This along with some of the other bizare issue that some of our developers have managed to get the working copies into have lead me to create a set of Subversion Commandments that might prove helpful.

1. Make sure your developers understand Subversion, what it is, what it does and how local checkouts are managed. They will mess up their local copies from time to time and need to fix the problem.
2. Make sure your developers understand how to move and rename files in the repository. Failure here will result in disconnected change history.
3. Make sure your developers understand the operational/mental difference between using Subversion and any “file by file” Source Control they have used before, such as Source Safe.
4. Before using subversion in anger let one developer spend the time to REALLY understand Subversion. This will be your Guru that others go to for help.
5. Make sure your developers ask your Guru for help WHENEVER they hit an issue. Letting them try and fix things results in f**k ups like the one that made me write this post.
6. It you plan on using tools like TortoiseSVN make sure your developers understand command line SVN. This will give them an understanding of Subversion that tools like TortoiseSVN can mask.
7. Create a FAQ document that details how Subversion should be used for all the common actions your developers need to perform. This will help new team members come up to speed etc.
8. Avoid strange repository structures. Stick with the standard Trunk, Branches, Tags layout (However they are named). It is how Subversion is designed to work.
9. Spend the time going through your project and add ignores for compile time files/directories and other generated files. It will stop developers committing them to the repository.
10. Every now and then look through how you developers are using Subversion and have polite words when you spot issues.

Subversion is a GREAT source control tool but my experiences with it at work have shown that some developers will get themselves into problems. You know the people, the ones that can interact with Humans, the ones that are not Autistic or have Aspergers

If you have any other commandments to add, let me know.

Subversion… a few months on.

Late last year the company I work for decided they had finally had enough of Source(Un)Safe, the aging source control from Microsoft which is as safe as printing out your projects source code then burning it.

The last major release branch of our source took 3 days on an 8 core system with fast raid array. One year on and fear was starting to set in as to how long the next branch would take.

We had looked at moving the development team to the Team System edition of Visual Studio for its updated source control but soon discounted that. You have to be a COMPLETE MORON to pay that much per seat.

Even though we are a Microsoft based shop we decided to look outside the Microsoft fold. Subversion was system that kept grabbing our attention. I spent the next week in evaluation of Subversion, TortoiseSVN and the Mindscape Visual Studio File Explorer then recommended the combination as the replacement Source Control for the company for a number of reasons.

• Well supported open, very active open source source solution.
• Many different tools available so not tied to one supplier.
• Works on all platforms. Windows, Linux and Mac.
• True Client/Server based solution.
• Easy to configure and use.
• TortoiseSVN has to be one of the best Source Control tools I have seen.
• We had a means to port the full change history from Source Control into Subversion.
• All related changes are stored as a single revision, not file by file like Source Safe.
• The Mindscape plugin for VS means you have full Source Control integration in the VS IDE.
• A code branch has ZERO cost.

The biggest change we found was the mindset shift from the Source Safe pessimistic style locking to the optimistic file locking offered by Subversion. Merge programming is never fun but as the supplied merge tools are easy to use that has not been an issue at all.

A few months down the line and I have to say it is the best move we could have made. There is not one member in the team that misses Source Safe, Subversion improves the Source Control experience on so many level.

f you still use Source Safe…. WHY? Subversion is a FREE, powerful and flexible replacement that will mean your source code actually is safe!