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:
- They only support Windows. It's got like 90% market
share, so why not?
- 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.
- If a software team has 450 Windows users and 50 people on
Mac or Unix, then a Windows-only solution just won't do.
- 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
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.
- 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
- 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..
- 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
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- On a Unix machine, checkin a symbolic link. Check it out
on Windows. What happens?
Like I said, things get quirky.