Well, I think it’s time to revisit.

I received an email on Tuesday from the “SourceForge.net Team” with the geeky and lame title of “SourceForge.net feature deprecation upcoming: forums, DocManager, TaskManager, Diary/Notes”. Deprecated should be deprecated from email subject lines, as should negative sounding email subjects.

The meat of the email is the second half (emphasis mine):

…

We will provide an easy-to-use migration path to move the data to the provided replacements.  We will also provide dumps of this data in case
projects want to do something different with their data.  Additional information on how to obtain or migrate your data will be provided when the
timeline is announced, in a future mailing.

The following applications are due to be deprecated, replaced by high-quality Open Source applications we have in our Hosted Apps offering:

* TaskManager will be replaced by TaskFreak!, dotProject and Trac
(tickets).
* DocManager will be replaced by MediaWiki and Trac (wiki).
* Discussion Forums will be replaced by phpBB.
* Diary and Notes will be replaced by WordPress.

To solicit your feedback on how the migration should be handled, and alternate options you would like us to consider, we are running a survey
for the next 30 days for the user base of each of these applications.  For links to the surveys, please see our Site Status post at:

http://tinyurl.com/q3g8o3

Trac and WordPress (really!) are two of my favorite open source web applications. And all of the applications in that list are highly regarded.

It’s fantastic to see SourceForge getting back to open source — ironic, no. It will be interesting to see how active they are in particulating in those projects. I dont’ think I’ve seen any SorceForge team members participating recently on WordPress’s Bug Tracker (Trac).

It’s also fantastic to see SourceForge engaging their community by posting this on a WordPress powered blog and also using surveys to solicite feedback about the migrations and the tool choices.

I would love to find out how long this change has been in the works and what people made it happen.

I also notice that SourceForge’s own documentation is now in a trac wiki. Wow, as well as Subversion, you can also use either Mercurial or Git.

The SourceForge team has done an incredible amount for open source, and I’m excited to reconsider using SourceForge.net again to future projects.

They allow us to do stupid things, mostly in error, but sometimes because we are too smart for our own good. There is no good reason for their (continued) existence.

I imagine that in the ancient days of computing it came about something like:

“Long file names will take up too much space”

“I know, we can make the file system case sensitive.”

“Great, now instead of ‘work-notes.txt’ and ‘notes-about-homebuilding.txt’, I’ll just name the files ‘notes’ and ‘Notes”.

Software developers are known for our passion for backward compatibility, and so today the popular file systems of Linux and Unix (except Mac) are still case sensitive.

Gross!

What has gotten me worked up about this (again)?

The cause this time is a customer checked into subversion two copies of a file just with different case. From the commit log, it seems likely that they meant to rename the file.

When I tried to update (or check out) the repository on Mac OS X (10.5.6), a case preserving, but case-insensitive file system (doing the right thing), it fails with a cryptic message:

svn: In directory 'images/author_header'
svn: Can't copy 'images/author_header/.svn/tmp/text-base/belief.jpg.svn-base' to 'images/author_header/.svn/tmp/belief.jpg.tmp.tmp': No such file or directory

using the pre-packaged svn 1.4.4 (r25188 – built Nov 25 2007). Out of interest, I used macports to upgrade to 1.5.5 (r34862) and the error is different but equally cryptic:

svn: In directory 'images/author_header'
svn: Can't open file 'images/author_header/.svn/tmp/text-base/belief.jpg.svn-base': No such file or directory


At this point, I had not identified the cause of the problem, so I was quite frustrated. Thankfully, I had a Linux box to check out the repository on and from there the issue looked obvious.

Solutions?

Save us from our selves.

When working on developing the next great file system, make it so amazing that you can slip in case preserving, case insensitivity like Mac OS X’s HFS+ (Mac OS Extended).

When developing tools like the next great revision control system don’t allow files of the same name but different case — the default configuration anyway.  Failing that, have good error messages. 

It’s not too late for Subversion either to fix the long rotten issue 667: handle file name case sensitivity edge cases (issue 2010: case sensitivity problem with checkout )

Update April 2, 2011: two years later, newer version of Mac OS X, and SVN, and I encounter the same problem:

$ svn up
svn: In directory 'macleans3/images/maps'
svn: Can't open file 'macleans3/images/maps/.svn/tmp/textbase/BQ_old.png.svn-base': No such file or directory

Again, after looking around for easy solutions on the Mac, I just logged into a Linux box, and checked out there, removed the duplicate file names, and committed.