2009-04-13 18:16:27

Ten Quirky Issues with Cross-Platform Version Control

A big chunk of the software industry today can mostly ignore the issues of multiple platforms, for one of the following reasons:

1. They only support Windows.  It's got like 90% market share, so why not?
   
   
2. They serve a web application and don't care what the end user is actually using as long as their browser works.

But version control tools involve more cross-platform concerns than most other kinds of software.  Neither of the reasons above tends to work very well.

1. If a software team has 450 Windows users and 50 people on Mac or Unix, then a Windows-only solution just won't do.
   
   
2. Since a primary task of a version control tool is to manage source code trees on the user's hard disk, a web application just won't do.

So, even as most coders have moved on to a world where they can remain blissfully ignorant of the problems of writing software for multiple operating systems, those of us who create version control tools are still wrestling with those problems.

And in fact, I claim that our challenges are tougher than most.  Version control users ask for the darndest things, especially in the big enterprise companies.  It's easy to believe that all you need is Windows, Mac, Linux and maybe Solaris.  Then you find out just how prevalent things like AIX and HPUX are.  Terms like "Irix" and "Win95" and "mainframe" get tossed around until you're numb and nothing surprises you anymore.  When somebody asks for a port to an arcane platform, you roll your eyes and wonder is if it uses 8-bit bytes or not.

Worse than that, version control vendors aren't just porting to oddball operating systems.  We actually have to make our software interoperate across all those environments.

And that's where things start to get quirky.

1. On a Linux system, create a file called "README".  In the same directory, create a file called "readme".  Check them both in.  Now go to a Mac and check them both out.  Since the Mac file system is [usually] case insensitive, something bad is going to happen.  Same goes for Windows/NTFS.
   
   
2. On a Mac, checkin a file called "PRN".  Check it out on a Windows system.  That file name is not allowed under Windows, for backward compatibility with MS-DOS..
   
   
3. Under Linux, checkin a file with a name that ends in a dot.  Check it out under Windows.  The trailing dot is probably gone.  Now check the file back in and go back to your Unix system.  If your version control system handled this badly, you've probably got two copies of the file, one with the trailing dot, and one without.  Same goes for a trailing space.
   
   
4. On a Linux system, checkin a file with a path that is 261 characters long.  Check it out under Windows.  This might work.  It probably won't.  It kind of depends on whether .NET is involved or not.  There's a \\?\ trick to get around the limitations of the Win32 layer, but the .NET libraries don't use it.
   
   
5. On a Mac, checkin a file that has a resource fork and some Finder info.  Check it out on a Linux machine.  What happens?  Did stuff show up as xattrs?  Should it have?  On that same Linux machine, make a change and check it back in.  Then check it out on the Mac again.  Is the Finder info still there?
   
   
6. On a Linux machine, checkin a file with a colon in the name.  Check it out on a Mac.  Not sure what'll happen, but it probably won't be what you want.
   
   
7. On a Windows machine, checkin a file with a name that begins with a dash.  Now check it out under Linux and try manipulating it with command-line utilities.  Apps will think the filename is a command-line option.  What if somebody creates a file named "-rf *" and a Linux user tries to rm it?  OK, bad example.  The point remains:  Filenames which begin with a dash may cause more problems on some platforms than on others.
   
   
8. On a Linux machine, create a source code file and check it in.  Check it out on Windows and open it with notepad.  The line-endings are Unix-standard LF, but Windows apps expect CRLF, so notepad shows the entire file as one line.  Now open the same file under Visual Studio.  The file looks fine now.  Now edit a few lines in the middle of the file, check it back in, and check it out on Linux again.  The lines you edited are messed up.
   
   
9. On a recent Ubuntu Linux system, create a file called "Español".  Do the same thing on Mac OS X 10.5.  These two files have the same name, but even though you are [probably] using the utf-8 encoding of Unicode on both systems, the bytes which represent that name do not match.  On the Linux machine, the file name [probably] will be in NFC normalized form (Espa\u00f1ol).  On the Mac, everything gets normalized to NFD (Espan\u0303ol).  When you check these files in and start working with them, bad things will happen unless your version control tool understands what's going on and deals with it appropriately.
   
   
10. On a Unix machine, checkin a symbolic link.  Check it out on Windows.  What happens?

Like I said, things get quirky.