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

Microsoft + DOS + Tom Tom = !Mono

I spend most of my working day programming C# in Visual Studio 2008. It is a great platform for Windows based development so when I made the move to Linux at home it made sense to look at Mono as a development environment for that platform.

The core of .NET is an ISO standard so in theory should be safe to use and since the backlash through the Open Source community over the Microsoft/Novell deal it did appear Microsoft was trying to play better with the Open Source.

Notice the “did” in that last sentence!

At the end of last week Microsoft showed it’s true colours and took it’s first real patent snipe at Linux over a very questionable FAT related patent on long file names.

Microsoft are far too scared to take on Linux directly. The threat of the patent cache held by the Open Source Initiative, backed by the likes of IBM, could cause serious damage to Microsoft if pushed too hard. A direct attack also risks them having to defend the patent in court, a massive risk after a few recent rulings against software patents as they could lose this lucrative patent.

Instead they have taken the easier route of attacking a small company, Tom Tom, which they know don’t have the funds to mount a defence. This allows them to link Linux with patent infringement in the media with little risk to their own software patent cache.

The patents in question relate to long file names in DOS, which is only able to deal with 8.3 based file names. The patents detail an obvious and a simple hash system for storing and mapping long file names to the DOS short file names.

Why does this matter to Linux?

FAT is the most common file format used on all Flash based storage, such as memory cards. If you want your Linux box to read your phone or camera memory cards you need to interact with DOS. This is another play by Microsoft to raise the cost of Linux distributions from $0, a price they are unable to compete with.

How does Mono fit into all this. In a sense it doesn’t. The only connection is Microsoft, the CONVICTED monopolist! But that c0nnection is enough to make me realise I should not be using the likes of Mono under Linux. What patent traps are buried in Mono waiting for the time that makes the direct attack on Linux a worth while move for Microsoft.

If you are thinking of using Mono in a Linux project then think hard and long. Do you really want to give Microsoft another attack vector?

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!

Life without debug, NUnit saves the day.

As I am new to Linux the last thing I decided I would use is Beta software. I am still not 100% sure on what is installed where and how to clean up when things go wrong so this is a good measure to keeping a stable system.

The downside to all this means I am stuck on MonoDevelop 1.0 and hence no debugger, that is due with the planned release of 2.0 near the end of the year.

It has been many many years since I have developed without the ability to debug and at times it has been hard work. When you dry run in your head you always miss things. I am just glad I got into the habit of unit testing everything when my day job enforced it. I could never have found some of the stupid bugs without the tests.

If you are a developer and do not use unit tests yet, WHY? The idea behind them is simple, you create test functions that make sure your code does what you expect it to do. NUnit is a common framework that makes creating and running the tests very easy. It does take a while to get into the habit and at first your find yourself wanting to just get on and code and skip the tests. You don’t start to see the real big benefits until you have good code coverage. Then you can start to make huge refactor changes in the knowledge everything that used to work still does without the need for long drawn out hand testing of everything again.

Without NUnit I would have given up on Mono by now, at least until the debugger was out. With NUnit I have the core of my code up, running and tested. I just need to create the thin code layer of the UI now and job done.

Mono, a Visual Studio replacement?

I first encountered Mono a few years ago and have tracked it ever since. I have never downloaded or used because I never needed to, I was Windows based and had Visual Studio for my development needs.

Since the switch to Linux I have been thinking about what development platform I should pick. Java and C# were the two logical choices for me as I have a C/C++/C# background. Both allow cross platform development but when I noticed Mono now supports the C# 3.0 language features it was a simple choice.

Many Linux and Open Source people will curse me for picking a system that carries patent risks with Microsoft. Personally I do not understand the problem, the core part of Mono only implements the parts of the .NET that have been turned over to standards bodies and hence carry no patent threats. The Gnome development team were satisfied enough to build Mono into Gnome, a decision that I doubt they rushed into.

.NET has matured into a stable platform since the dire initial release. There are now many languages at your disposal including Python in the form of IronPython. All interact with the runtime in the same way which means you can mix and match languages and pick the one best for the task at hand.

The MonoDevelop IDE feels very raw coming fresh from VisualStudio 2008, it is nowhere near as polished as the Microsoft offering which I think has matured into one of the best there is. I am using MonoDevelop V1 at the moment because V2 is beta so it will be interesting to see what that brings to the mix.

I have started my first cross platform project so I will talk more about Mono as I use it in anger, but I am very happy with the platform from my initial investigation and cut code. Not having to pay for upgrades evry few years is also a BIG bonus as Microsoft development tools are NOT cheap if you want to actually release code.