Don't you like to review your changes before committing them?
I do, but I don't appreciate being pushed towards Linus' preferred idiosyncratic approach to it. I have my own way of reviewing changes, and a well designed tool doesn't unnecessarily push you towards some idiosyncratic workflow preferred by the tool's author. The staging area reminds me of one of those tools that says "are you you sure you want to do this, you do realize that changes made here are not easily undone, please confirm you want to do that, now, are you absolutely positively cross your heart sure you want to do that?". I find such an approach makes me more likely to screw up.
Whether you prefer to include all modifications in a commit is a workflow driven decision.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity. I'm also very careful about checking things before a commit, but I don't appreciate being pushed towards Linus' idiosyncratic way of doing that. I have my own approach. YMMV, but I find the extra step means I'm more likely to make a stupid mistake.
I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.
It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.
* no way to ignore files easily
* no way to branch easily
* mixed-revisions, it's a nightmare
Which is completely OT. This thread is about repository corruption. It's typical of the knee-jerk response I see to any talk of anything other than Git though.
Interesting though that FogBugz originally went w/ Hg instead of Git. Obviously they have to support what their customers want. However, it seems that several outfits (e.g. Google) that really looked at the two originally chose Hg, and have since come to support Git only by popular demand. I'm not convinced that popular demand was driven by anything other than "Git is what the cool kids use, because Linus the ultimate cool kid uses it'.
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.
Thanks for the advice. I'll look into some of the Hg GUI stuff you mention. Unfortunately we're stuck w/ Windows clients as that's what our cross-dev tools run on. I've played w/ Git, including TortoiseGit and came to similar conclusions as you. It seems to me like Hg gets short shrift.
All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.
There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.
I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.
Documentation is also one of the strong points of SVN. The online book is fantastic.
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).
At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
I know I could overcome that problem by switching to Mercurial or Git, and I'd love to, but it's not a good idea with my team. Several of them are very good at what they do (Ph.D.'s in signal processing and detection and estimation) but have little interest in learning what is, for our purposes, the more complicated DVCS approach. Sometimes I feel lucky I got them to use VC at all, and it helps that the svn UI is a lot like the CVS that some of them already knew.
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.
Pervy Old Men are going to use it upside down, and enjoy (depending on the mood) afterwards in home.
What's with the ageism? A walking stick is not the same as a cane. Walking sticks were once used by foppish men of all ages - just look at a bottle of Johnnie Walker. If Google is successful at reintroducing this fashion, you needn't be left out.
So an individual shouldn't be allowed to put on a TV advertisment for their favorite political person within 90 days of an election?... That is specifically what the Citizen's United case was decided on.
Wrong on multiple levels. First, we're not talking about individuals as there is nobody named "Citizen's United". Second, you're only talking about the original complaint, which was arguably reasonable. However the "conservative" Supreme Court, which is supposedly dedicated to hearing cases about "actual harm" and deciding them on the narrowest possible grounds, engaged in an unprecedented act of procedural corruption by asking the plaintiff to go back and tremendously broaden the scope of the complaint. That allowed our "conservative" Supreme Court, which is ever so critical of an activist judiciary, to effectively create their own case to decide based on their ideology.
Ummm, the North sea has huge storms that create exactly the same tidal surges.
Ummm, no. The North Sea flood of 1953 had storm surges of 18'. Katrina had surges of 27'.
ever heard of the Thames barrier?
Because London is well upstream from the sea, the Thames barrier is only 1700' wide. If that's all there was to it, it'd be easy.
Half of all the people who live in coastal US cities now live below sea level.
Cite?
And if half of all the people who live in coastal US cities now live below sea level, how do they manage it without the sort of levees that surround New Orleans?
some parts of Mexico city have sunk nearly 100ft in the same timespan!
Luckily for them they're 7000' above sea level.
comparing Amsterdam to New Orleans proves beyond all reasonable doubt is that spending billions of tax dollars building and maintain seawalls is by far the cheapest and most humane solution
It proves nothing because you haven't even offered a guess of the cost of protecting New Orleans, and you fail to take into account that unlike the Netherlands the US has lots of land above sea level. I also fail to see what's inhumane about offering people some free money if they wish to move to higher ground.
I think its BULL that a corporation should even seek to be protected by the US Constituion that was written to protect citizens of this country, not corporations. Corporations have priviledges, not rights.
The 1st Amendment is written as a negative right, by which I mean it prohibits the government from doing certain things ("Congress shall make no law... abridging the freedom of speech..."). It is not written as a positive right, like "people shall have the right of freedom of speech". It's good that it's written that way as otherwise it wouldn't protect news organizations, which are often corporations. It's also important because Freedom of Speech means not only the right to speak, but the right to listen to what anyone or anything (even "artificial persons") has to say.
This does not mean that I'm a supporter of things like the Citizens United decision, which I think is one of the most absurdly corrupt decisions the court has ever issued. The problem there though, and with many of the other decisions on campaigns and financing, is that it takes the "money = speech" idea to absurd extremes. If money is speech, does that mean that I have a Constitutionally protected right to hand my congresscritter a suitcase full of unmarked bills?
we hear all kinds of talk of this sort when Katrina hit New Orleans...why aren't we now talking of moving NYC and those cities in NJ built so dangerously close to the ocean. Where are all the calls saying we shouldn't be rebuilding there....etc?
Because NYC at least starts out above water before the storm. Seriously, I don't mean this as an anti-New Orleans snark, but starting out below sea level doesn't seem like a winning proposition. I know the Dutch manage it, but they don't get many hurricanes. Also half of their country is below water, whereas most of the US, even most of Louisiana, starts out above sea level.
I don't know what the realistic (including politics) answer is. There are parts of NYC, like the Rockaways, that should never have been built on. They're barrier beaches that a good wave can wash over. I doubt they'll be abandoned though. What can be done about NO? It doesn't seem outrageous to offer people an incentive to leave so that the city can be shrunk, but I know that "shrinking" a city isn't an easy task. At the very least though NO shouldn't be expanded. Unfortunately it makes no sense. Maybe we need a Newer Orleans on higher ground?
I enjoy video games, programming and driving...
For some of us, $50K for a car that we enjoy driving is neither a particularly momentous expense, nor an attempt to prove anything. It's an indulgence, of course
Go ahead and enjoy your hobby, just don't complain too much when the price goes up. If self-driving cars become practical and commonplace, wetware guided cars may be justifiably banned from the public roads as unsafe. Of course you should be able to use a private road or track, but that may be pricey. With the resultant greatly reduced demand for wetware guided cars, they may become a very expensive low-volume specialty item too.
Big rig truckers may be secure for at least awhile as well...
There is a much older technology that could reduce the number of big rigs - trains. I don't like to see anyone other than bean counters and MBA's out of work, but it makes little sense to have one person driving one load a thousand miles or more. For anything over 200-300 miles it makes more sense to use a train most of the trip, even taking into account the truck to train (and vice versa) transfer that usually has to take place for more local delivery. The hybrid truck-train approach saves fuel and labor costs. What I don't understand is why it isn't more widely used. Computerized routing and tracking of freight cars makes the whole process simpler, and even many years ago you could ship things cross-country in little more or even less time than a truck.
I agree. Hauling a heavy load is more of a physics problem, which is tough for a person but where a computer/robot shines. Take ABS and traction control for example. Yes, it's much simpler than controlling the whole vehicle, but it is something we've had for years and where the automated system works better than any human. ABS has speed sensors for each wheel - try getting a human to keep track of that. Similarly autopilots have been around for years, even though (despite Google hype) we're nowhere near self-driving cars. The things that make it tougher for a human to learn to fly rather than drive, like controlling something in 3 dimensions where you can't rely on your sense of balance, or simultaneously controlling roll and yaw in order to bank properly, are comparatively easy for a computer to handle.
By contrast the cabbie has to judge whether the idiot on his cell phone is going to stop at the curb or walk in front of the cab. That's a much tougher problem for a computer, even in the best of conditions. Limited access road driving is the easiest thing type of driving to automate precisely because access is limited.
Slashdot Mirror
Don't you like to review your changes before committing them?
I do, but I don't appreciate being pushed towards Linus' preferred idiosyncratic approach to it. I have my own way of reviewing changes, and a well designed tool doesn't unnecessarily push you towards some idiosyncratic workflow preferred by the tool's author. The staging area reminds me of one of those tools that says "are you you sure you want to do this, you do realize that changes made here are not easily undone, please confirm you want to do that, now, are you absolutely positively cross your heart sure you want to do that?". I find such an approach makes me more likely to screw up.
Whether you prefer to include all modifications in a commit is a workflow driven decision.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity. I'm also very careful about checking things before a commit, but I don't appreciate being pushed towards Linus' idiosyncratic way of doing that. I have my own approach. YMMV, but I find the extra step means I'm more likely to make a stupid mistake.
I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.
It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.
SVN:
* no way to ignore files easily * no way to branch easily * mixed-revisions, it's a nightmare
Which is completely OT. This thread is about repository corruption. It's typical of the knee-jerk response I see to any talk of anything other than Git though.
Interesting though that FogBugz originally went w/ Hg instead of Git. Obviously they have to support what their customers want. However, it seems that several outfits (e.g. Google) that really looked at the two originally chose Hg, and have since come to support Git only by popular demand. I'm not convinced that popular demand was driven by anything other than "Git is what the cool kids use, because Linus the ultimate cool kid uses it'.
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.
Thanks for the advice. I'll look into some of the Hg GUI stuff you mention. Unfortunately we're stuck w/ Windows clients as that's what our cross-dev tools run on. I've played w/ Git, including TortoiseGit and came to similar conclusions as you. It seems to me like Hg gets short shrift.
All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.
There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.
I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.
Documentation is also one of the strong points of SVN. The online book is fantastic.
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).
At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
I know I could overcome that problem by switching to Mercurial or Git, and I'd love to, but it's not a good idea with my team. Several of them are very good at what they do (Ph.D.'s in signal processing and detection and estimation) but have little interest in learning what is, for our purposes, the more complicated DVCS approach. Sometimes I feel lucky I got them to use VC at all, and it helps that the svn UI is a lot like the CVS that some of them already knew.
Heretic! Real programmers use Git. Nobody else gets to sit at the cool kids' table.
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.
Sergey Brin is getting old just as fast as anyone else. Already having sufficient retirement funds, he plans ahead in other ways.
Pervy Old Men are going to use it upside down, and enjoy (depending on the mood) afterwards in home.
What's with the ageism? A walking stick is not the same as a cane. Walking sticks were once used by foppish men of all ages - just look at a bottle of Johnnie Walker. If Google is successful at reintroducing this fashion, you needn't be left out.
That's already covered by numerous Japanese patents.
So an individual shouldn't be allowed to put on a TV advertisment for their favorite political person within 90 days of an election? ... That is specifically what the Citizen's United case was decided on.
Wrong on multiple levels. First, we're not talking about individuals as there is nobody named "Citizen's United". Second, you're only talking about the original complaint, which was arguably reasonable. However the "conservative" Supreme Court, which is supposedly dedicated to hearing cases about "actual harm" and deciding them on the narrowest possible grounds, engaged in an unprecedented act of procedural corruption by asking the plaintiff to go back and tremendously broaden the scope of the complaint. That allowed our "conservative" Supreme Court, which is ever so critical of an activist judiciary, to effectively create their own case to decide based on their ideology.
Ummm, the North sea has huge storms that create exactly the same tidal surges.
Ummm, no. The North Sea flood of 1953 had storm surges of 18'. Katrina had surges of 27'.
ever heard of the Thames barrier?
Because London is well upstream from the sea, the Thames barrier is only 1700' wide. If that's all there was to it, it'd be easy.
Half of all the people who live in coastal US cities now live below sea level.
Cite?
And if half of all the people who live in coastal US cities now live below sea level, how do they manage it without the sort of levees that surround New Orleans?
some parts of Mexico city have sunk nearly 100ft in the same timespan!
Luckily for them they're 7000' above sea level.
comparing Amsterdam to New Orleans proves beyond all reasonable doubt is that spending billions of tax dollars building and maintain seawalls is by far the cheapest and most humane solution
It proves nothing because you haven't even offered a guess of the cost of protecting New Orleans, and you fail to take into account that unlike the Netherlands the US has lots of land above sea level. I also fail to see what's inhumane about offering people some free money if they wish to move to higher ground.
I think its BULL that a corporation should even seek to be protected by the US Constituion that was written to protect citizens of this country, not corporations. Corporations have priviledges, not rights.
The 1st Amendment is written as a negative right, by which I mean it prohibits the government from doing certain things ("Congress shall make no law ... abridging the freedom of speech ..."). It is not written as a positive right, like "people shall have the right of freedom of speech". It's good that it's written that way as otherwise it wouldn't protect news organizations, which are often corporations. It's also important because Freedom of Speech means not only the right to speak, but the right to listen to what anyone or anything (even "artificial persons") has to say.
This does not mean that I'm a supporter of things like the Citizens United decision, which I think is one of the most absurdly corrupt decisions the court has ever issued. The problem there though, and with many of the other decisions on campaigns and financing, is that it takes the "money = speech" idea to absurd extremes. If money is speech, does that mean that I have a Constitutionally protected right to hand my congresscritter a suitcase full of unmarked bills?
But a libel suit would still look bad for Google. This is a PR issue, and you don't win those by filing libel suits.
Is an article on Slashdot complaining about fanboys and trolls ironic or just plain futile?
we hear all kinds of talk of this sort when Katrina hit New Orleans...why aren't we now talking of moving NYC and those cities in NJ built so dangerously close to the ocean. Where are all the calls saying we shouldn't be rebuilding there....etc?
Because NYC at least starts out above water before the storm. Seriously, I don't mean this as an anti-New Orleans snark, but starting out below sea level doesn't seem like a winning proposition. I know the Dutch manage it, but they don't get many hurricanes. Also half of their country is below water, whereas most of the US, even most of Louisiana, starts out above sea level.
I don't know what the realistic (including politics) answer is. There are parts of NYC, like the Rockaways, that should never have been built on. They're barrier beaches that a good wave can wash over. I doubt they'll be abandoned though. What can be done about NO? It doesn't seem outrageous to offer people an incentive to leave so that the city can be shrunk, but I know that "shrinking" a city isn't an easy task. At the very least though NO shouldn't be expanded. Unfortunately it makes no sense. Maybe we need a Newer Orleans on higher ground?
Who would want NYC moved to their neighborhood or within 200 mile thereof.
You should be so lucky you m*****f***ing rube.
P.S. Note, contrary to stereotype, the politeness of the native New Yorker.
I enjoy video games, programming and driving ...
For some of us, $50K for a car that we enjoy driving is neither a particularly momentous expense, nor an attempt to prove anything. It's an indulgence, of course
Go ahead and enjoy your hobby, just don't complain too much when the price goes up. If self-driving cars become practical and commonplace, wetware guided cars may be justifiably banned from the public roads as unsafe. Of course you should be able to use a private road or track, but that may be pricey. With the resultant greatly reduced demand for wetware guided cars, they may become a very expensive low-volume specialty item too.
Big rig truckers may be secure for at least awhile as well ...
There is a much older technology that could reduce the number of big rigs - trains. I don't like to see anyone other than bean counters and MBA's out of work, but it makes little sense to have one person driving one load a thousand miles or more. For anything over 200-300 miles it makes more sense to use a train most of the trip, even taking into account the truck to train (and vice versa) transfer that usually has to take place for more local delivery. The hybrid truck-train approach saves fuel and labor costs. What I don't understand is why it isn't more widely used. Computerized routing and tracking of freight cars makes the whole process simpler, and even many years ago you could ship things cross-country in little more or even less time than a truck.
I agree. Hauling a heavy load is more of a physics problem, which is tough for a person but where a computer/robot shines. Take ABS and traction control for example. Yes, it's much simpler than controlling the whole vehicle, but it is something we've had for years and where the automated system works better than any human. ABS has speed sensors for each wheel - try getting a human to keep track of that. Similarly autopilots have been around for years, even though (despite Google hype) we're nowhere near self-driving cars. The things that make it tougher for a human to learn to fly rather than drive, like controlling something in 3 dimensions where you can't rely on your sense of balance, or simultaneously controlling roll and yaw in order to bank properly, are comparatively easy for a computer to handle.
By contrast the cabbie has to judge whether the idiot on his cell phone is going to stop at the curb or walk in front of the cab. That's a much tougher problem for a computer, even in the best of conditions. Limited access road driving is the easiest thing type of driving to automate precisely because access is limited.