In the UK with the NHS, there is no concept of a medical ailment which is uninsurable. This is a little controversial, because a proportion of the NHS's costs go on treating people who are sick because they are smokers, are obese, or do drugs etc. Likewise for treating people who injure themselves mountain climbing or taking part in other "dangerous pursuits". The NHS also treats unusual/exotic diseases, usually contracted by people who travel to tropical countries, and it operates a specialized hospital for treating these. The health service will never say to you "sorry, we don't cover that".
In fact in the UK people do not really even see the NHS as insurance, beyond the line on their pay slip which says "national insurance". They just know that if they get sick, they go to the doctor. The doctor may refer them to hospital, and there they may receive more tests or may be scheduled for surgery. We never have to fill in insurance forms. We never get turned away by the doctor or told "sorry, your policy does not cover that".
A properly implemented national health insurance system will not turn people away for any reason. The private system you are defending restricts your freedom by preventing you from taking part in pursuits you cannot afford to insure yourself for.
Your child's ruptured eardrum reminds me of my history in that department. I had glue ear as an infant. This is pretty common, and easy to fix, but it needs to be fixed quickly as there is some evidence that, unchecked, it can lead to meningitis. So, they put in vents which drain out the fluid. The vents are supposed to fall out over time, and the hole in the eardrum then closes up.
Since I'm a quirk of nature, the vents didn't fall out, so I had to visit hospital again where the doctor removed them. More quirkiness when the holes they left behind didn't heal up, so I visited again, this time for a procedure where they graft a little piece of skin from behind your ear onto your eardrum. It closed up just fine.
My parents didn't have to pay a single penny for any of this up front. It was all done on the NHS - three or four hospital stays several days long, countless checkups and hearing tests, surgical procedures, prescription drugs, the works.
The NHS can obviously have limitations. A friend of mine had a collapsed lung, and underwent emergency treatment in an NHS hospital to reinflate it. It recurred again, the NHS fixed it again, and then the doctor advised that he would have to undergo a procedure to fix it permanently. The waiting list for this was three months. Of course, during this time there was any possibility that the collapse could occur again.
Since his parents had a private health insurance policy which covered him, he decided to go that route to get it done. The operation was performed within a week, and now there have been no further problems.
The point here is that there is still business for private health hospitals who can provide the "bells and whistles" hotel-room care, and at short notice, for those who wish to pay the premium. Because the NHS exists and is "good enough", the private hospitals have to compete on price and value. This kind of competition does not appear to exist, or to work effectively, in the theoretically free market implementation which exists in the USA.
What is bizarre to me is the way that some Americans will say that they are opposed to "socialized health care". The big news here is that you guys already have "socialized" healthcare - but because there's a massive effort to disguise it, you have to pay a lot more for it. For example, many US hospitals will treat people who cannot afford care (and they are legally obliged to provide emergency room treatment). Who pays for that ? Simple, the costs are passed on in the form of higher charges to the insurers, or those who can afford to pay. What happens if they bill someone for treatment, and that person cannot pay ? The person goes bankrupt and their debts have to be written off. Employer health insurance schemes all have various tax rebates provided by the government - which effectively means that the government is subsidizing healthcare.
And that's before the bureaucracy. In the NHS, doctors have to go to some effort to be careful about how many prescriptions they hand out, how many more hospital checks, tests or procedures are run - there is a rationing system ("fundholding GPs"). The doctors do not have to spend hours fighting with insurance companies over whether someone should receive such and such a procedure or not. Since it is relatively easy to perform preventative surgery on the NHS, the system does not have to incur the cost of doing more serious surgery later on.
Gov't run health care? No thanks. I hate the DMV enough to have an idea of what that will be like.
Works well enough in the UK. But if you'd rather be shafted by insurance companies, middle men, and family doctors on commission from the big pharma, I guess that's your prerogative.
Gov't run energy? No thanks. I like my lights on, not freezing to death while those clowns debate in committee what energy bracket I'm in to determine how much I'm allowed to heat my home.
Has any politician in the USA been able to seriously propose the privatization of the TVA, and have a political career ?
Given that the Republicans are still blaming the Democrats for the current problems, problems that the Republicans didn't address during 8 years of control of Congress, I'm sure we can give a bit of levity to those of us who could never come to terms with the incoherent dangerous idiot you elected to lead your country.
VSS is probably one of the worst VCSs ever conceived, worse even than SVN. You clearly have a very limited experience of real-world team oriented software development.
If you think that the the four points you raised are relevant to a commercial organization, then you probably haven't worked in one for very long, if at all. Cost of ownership is what is important, not the cost of the tool. And since the set of companies working on VCS tools is a small subset of the set of all companies doing software development, the non-compete clause (which is common enough in the commercial world) isn't a problem either.
And "critical mass" as in lots of cool bells and whistles is not as important as stability, ease of use and reliability. Open source projects are not driven by commercial concerns, but by whatever the maintainer of the project thinks is cool and whatever a programmer decides would be fun to implement. You're giving away your time for free - why would you spend it doing boring stuff like fixing hard concurrency bugs instead of adding whizzy cool things ?
That is all fine - I am not saying that open source projects must be driven by commece - but this is a limitation that you need to be aware of when you (in a commercial role) decide to adopt open source tools. Of course, there are many many cases where this all works out fine - Linux itself being one of those.
Now imagine someone pushes a major refactorisation directly onto your working tree, which does not merge cleanly
You deal with that by locking out the destination tree and attempting to apply the merge as an atomic transaction. If it cannot be applied because the user has already begun making modifications, then you abort the transaction and rollback to the point you were at before.
For most commercial organizations, maintaining (including managing change, testing and QA) or their own revision control software is not an option, so having the source code available is not a big selling point. Sure, it's nice to have that flexibility just in case, but in practice it is unlikely you will need it. And to be honest, I really don't give a damn how git works and the less I need to know, the better. My customers don't pay me to be an expert in Git's implementation.
What is more valuable to a commercial organization is the option to pay someone to fix problems when they arise and provide support. If I have a bug that's causing me problems with development, I want to fix it now. Not to have to reassign a team of developers to figure it out.
So I think your argument certainly applies in the open source world, but not for commercial organizations. That's cool - apples and oranges.
That is a fair point - git isn't good for looking at isolated parts or individual files in a repository. But I see it really as a matter of optimizing for the common case. Normally, I need to see the whole repository. Normally I don't need to just look at one file. Git will checkout an entire repository along with all the history faster than SVN will, in the tests that I did.
BTW if I just want to look at one file in Git I use the web interface. That gets around the problem by querying into the main repository.
What you're supposed to do in Git is organize your source code into submodules. This takes very little effort, but you have to do it when you migrate.
SVN does let you check out subdirectories, but that is a strength which is perversely afforded by one of its main limitations. SVN does not track the state of the repository globally. Of course, if you want to track the whole repository state, then you cannot allow people to modify subdirectories independently.
I do typical corporate development, and I don't think centralized repositories are best. I love being able to create my own independent sub-project and ask other developers to contribute to it. What possible reason would there be to not have that functionality ? You do need development and delivery processes to govern where people do work and where it is delivered to, but you'll need those irrespective of which SCM you're using.
You can actually make Clearcase work quite well, without resorting to a baseball bat. The trouble is that you have spend a lot of time and money doing it, substantially more than with any other VCS.
A properly-configured and administrated Clearcase environment is very effective - but not good value for money, IMO. I don't believe there is any other revision control system that can do the build auditing stuff that CC does. Unfortunately, some of the ISO capability maturity model stuff seems to require this. I wonder if any IBM/Rational employees were on the standards boards..
Well, to use Clearcase properly you have to write a wrapper script that manages and updates the config specs for you. That's the part that they don't tell you when they're selling it to you. Ordinarily, users shouldn't be modifying the config spec.
I love the way when you change the Clearcase config spec and accidentally enter a typo, it doesn't tell you. So you get subtle changes in your repository that you don't expect. I've seen people spend days trying to figure out what was going on when they accidentally modified their config spec with an error.
It's not surprising that developers increasingly favour distributed version control. It's a much more flexible way to work - and if you need to continue working in a centralized way, you can still do that.
If you're migrating to Git, there are a few things you need to account for. Do you want to migrate the history, or make a clean break using the current head of the tree ? Migrating the history is usually hard if it is in a commercial tool, since commercial companies quite obviously do not design their tools to make it easier for you to abandon them (some provide export tools). If you choose not to migrate the history, you have the issue of having to keep the old revision control system around to debug/fix/review older releases.
You need to be clear about your decision. Import some example code into Git (perhaps from your existing repository), put it on a server and ask your developers to play with it to make sure they're happy with the feel and that they're confident they can work with it. Make sure you practice doing things like merging conflicts and merging older maintenance branches. If you do this right, most of your developers should be fairly enthusiastic about the switch when it comes. Make sure you account for Windows users - Git isn't so hot over on Windows and I don't think there is an official stable Windows release yet.
Other than this, there's really very little to it.
I'll pray for your soul. There's nothing worse than a group of managers who think that the world will get better when Clearcase is employed. I swear, that tool seems to be deliberately designed to slow you down.
It may be that a centralized VCS like svn may be a better option.
I cannot conceive of a scenario where this is true. In any case, you can use Git or any other distributed tool as a centralized VCS if you wish. Just tell all your developers to merge their code into the central location, and not to clone from each other's repositories. Dead easy. Although the idea that anyone would seek to make those restrictions makes no sense.
I think it's more popular for one of the same reasons that Bitkeeper initially became popular - it's being used by Linus for the kernel. Getting Linus to use one of your tools is one of the best marketing coups you can land. Outside of this, Bitmover is a small company and it's hard to see how they would have gotten the kind of exposure that they did with the kernel. That said, they seem to be surviving just fine today.
The other reason that it's popular is because it's free. This is fine for open source projects. In the commercial land, managers tend to underestimate the importance of good revision control tools and processes, and the importance of tools which make it easy to build and enforce those processes. Bitkeeper (and some of it's competitors) go to a lot of effort to provide both tools and processes. Git is not so good at this. Other tools that are not good at this include Clearcase (although UCM is an attempt, albeit a controversial one) and CVS.
And I wouldn't say that Bitkeeper and Git are the same. The underlying design concept - distributed version control, changesets, and the benefits that flow out of this eg proper merge tracking and a greater degree of determinism - are the same. Bitkeeper has much better GUI tools, and it's a lot more user-friendly; the command interface is coherent and consistent, and the commands are simpler and easier to remember, options that do similar things are the same across different commands. For example, the "-r" flag always refers to a changeset number, in any command that accepts this parameter. I used BK on a project with between 20 and 45 users; it never once corrupted the repository and there wasn't a single time when the server went down. There were a few times when things were weird when new users unfamiliar with the tool broke their repos, but that stopped after a couple of weeks. The real benefit is that it makes it very easy to see who broke what, and how - whether it was during development or during a merge.
Git isn't friendly or forgiving at all, and you need to really know what you are doing. There are operations that are very dangerous, like the rebase operation; BK does have an equivalent but it incorporates some basic measures to stop someone from messing up the repository they are pushing to.
Additionally, Git will break things in unexpected ways. Try pushing a change into another Git repository, then navigate to that repository and run "git status" - git does not auto-checkout changes in the destination repository during a push. It's the user's responsibility to detect this and deal with it. I find that design approach - the idea that the user is expected to spot and deal with the internal behaviour of the tool - to be pretty bad.
Linus says that anyone who thinks Git is hard to use is an idiot. Idiocy is not the problem here. The developers in the organization I work in do not want to have to know or care about how the internals of the tool work. They want to cut their code, merge it and integrate it as quickly and as effectively as possible. BK easily beats Git on this measure. On the other hand, Git is far and away the superior open-source revision control tool. Anyone who thinks that Subversion is better just doesn't get it.
The c-word is still very much socially unacceptable here (and in the US too - how often to you hear it in movies ? very rarely), so I don't see "git" as a weaker version of it.
I'd put "git" alongside "moron" or "jerk". Nobody's going to raise their eyebrows if you say it.
I find it less efficient if I run my own heating (heating a larger communal space is more cost effective), use my own electricity (offices get bulk rates), and then have to travel into work anyway if I need to meet a customer face to face.
I'm reasonably sure in Europe you could be sued if you refused to carry someone based on their religion or racial background - I have a feeling this is true in the US also ? If so, I hope they take this stupid airline to the cleaners. Even setting the obvious discrimination aside, there was no excuse for denying them travel given that the FBI had cleared them.
It's interesting how republics like the USA form their own family dynasties, possibly in the absence of an "official" one. Look at some of the senior/well known political clans. Political families (like the Kennedys or the Bushes) are almost unknown in UK politics.
And Americans love the British monarchy. Whenever it was announced that Prince William would be going to the University of St Andrews, the university was beseiged by applications from American teenage women (source), presumably all wanting to marry a likely future king.
If the untaxed diesel is dyed, then it is straightforward to check if someone has been using it inappropriately by dipping their tank. There's always some dye in there even if the driver subsequently refills with taxed diesel a few times.
If you do it the other way round then you can't easily prove that the driver used undyed diesel..
Maybe I'm missing something ?
On the Oregon matter, a simple way to protect revenue would be to change the tax so that it's a fixed price per gallon sold, rather than a percentage of the price of the gallon. This way the state always collects the same amount of tax revenue irrespective of the oil price.
The TGV is the result of a number of dynamics in France that aren't so easy to find elsewhere. France suffered a great deal of damage during WW2, and this made it easier to build new railway lines (TGV tracks are long and straight with only the most gradual curves). In addition, they created legislation that effectively ignored objections to the new rail lines being built through people's neighbourhoods. And finally, they assembled a large electricity industry built on nuclear power which provides the energy which powers the trains. I am not sure how easily this can be replicated in other countries.
High speed rail could be done in the US but it would require tremendous political will to face down the lobbyists from the airline industry. I think it could be made to work; surely for business people, an express overnight coast to coast service with sleeping facilities is much more attractive than the current almost full day that would be spent doing the same trip by air.
2)To the whiners who say "We don't have a hydrogen infrastructure" I reply with this: Hydrogen can be produced ANYWHERE there is water and electricity. Every gas station in the civilized world has WATER and ELECTRICITY. All we need to do is drop an electrolysis station in their parking lot. This can be containerized and done with tractor trailers.
And how do we provide the energy to power your portable electrolysis station ?
Slashdot Mirror
In the UK with the NHS, there is no concept of a medical ailment which is uninsurable. This is a little controversial, because a proportion of the NHS's costs go on treating people who are sick because they are smokers, are obese, or do drugs etc. Likewise for treating people who injure themselves mountain climbing or taking part in other "dangerous pursuits". The NHS also treats unusual/exotic diseases, usually contracted by people who travel to tropical countries, and it operates a specialized hospital for treating these. The health service will never say to you "sorry, we don't cover that".
In fact in the UK people do not really even see the NHS as insurance, beyond the line on their pay slip which says "national insurance". They just know that if they get sick, they go to the doctor. The doctor may refer them to hospital, and there they may receive more tests or may be scheduled for surgery. We never have to fill in insurance forms. We never get turned away by the doctor or told "sorry, your policy does not cover that".
A properly implemented national health insurance system will not turn people away for any reason. The private system you are defending restricts your freedom by preventing you from taking part in pursuits you cannot afford to insure yourself for.
Your child's ruptured eardrum reminds me of my history in that department. I had glue ear as an infant. This is pretty common, and easy to fix, but it needs to be fixed quickly as there is some evidence that, unchecked, it can lead to meningitis. So, they put in vents which drain out the fluid. The vents are supposed to fall out over time, and the hole in the eardrum then closes up.
Since I'm a quirk of nature, the vents didn't fall out, so I had to visit hospital again where the doctor removed them. More quirkiness when the holes they left behind didn't heal up, so I visited again, this time for a procedure where they graft a little piece of skin from behind your ear onto your eardrum. It closed up just fine.
My parents didn't have to pay a single penny for any of this up front. It was all done on the NHS - three or four hospital stays several days long, countless checkups and hearing tests, surgical procedures, prescription drugs, the works.
The NHS can obviously have limitations. A friend of mine had a collapsed lung, and underwent emergency treatment in an NHS hospital to reinflate it. It recurred again, the NHS fixed it again, and then the doctor advised that he would have to undergo a procedure to fix it permanently. The waiting list for this was three months. Of course, during this time there was any possibility that the collapse could occur again.
Since his parents had a private health insurance policy which covered him, he decided to go that route to get it done. The operation was performed within a week, and now there have been no further problems.
The point here is that there is still business for private health hospitals who can provide the "bells and whistles" hotel-room care, and at short notice, for those who wish to pay the premium. Because the NHS exists and is "good enough", the private hospitals have to compete on price and value. This kind of competition does not appear to exist, or to work effectively, in the theoretically free market implementation which exists in the USA.
What is bizarre to me is the way that some Americans will say that they are opposed to "socialized health care". The big news here is that you guys already have "socialized" healthcare - but because there's a massive effort to disguise it, you have to pay a lot more for it. For example, many US hospitals will treat people who cannot afford care (and they are legally obliged to provide emergency room treatment). Who pays for that ? Simple, the costs are passed on in the form of higher charges to the insurers, or those who can afford to pay. What happens if they bill someone for treatment, and that person cannot pay ? The person goes bankrupt and their debts have to be written off. Employer health insurance schemes all have various tax rebates provided by the government - which effectively means that the government is subsidizing healthcare.
And that's before the bureaucracy. In the NHS, doctors have to go to some effort to be careful about how many prescriptions they hand out, how many more hospital checks, tests or procedures are run - there is a rationing system ("fundholding GPs"). The doctors do not have to spend hours fighting with insurance companies over whether someone should receive such and such a procedure or not. Since it is relatively easy to perform preventative surgery on the NHS, the system does not have to incur the cost of doing more serious surgery later on.
Gov't run health care? No thanks. I hate the DMV enough to have an idea of what that will be like.
Works well enough in the UK. But if you'd rather be shafted by insurance companies, middle men, and family doctors on commission from the big pharma, I guess that's your prerogative.
Gov't run energy? No thanks. I like my lights on, not freezing to death while those clowns debate in committee what energy bracket I'm in to determine how much I'm allowed to heat my home.
Has any politician in the USA been able to seriously propose the privatization of the TVA, and have a political career ?
Given that the Republicans are still blaming the Democrats for the current problems, problems that the Republicans didn't address during 8 years of control of Congress, I'm sure we can give a bit of levity to those of us who could never come to terms with the incoherent dangerous idiot you elected to lead your country.
There's a good chance that this violates your ISP's terms of service. Other than that, cool.:)
VSS is probably one of the worst VCSs ever conceived, worse even than SVN. You clearly have a very limited experience of real-world team oriented software development.
If you think that the the four points you raised are relevant to a commercial organization, then you probably haven't worked in one for very long, if at all. Cost of ownership is what is important, not the cost of the tool. And since the set of companies working on VCS tools is a small subset of the set of all companies doing software development, the non-compete clause (which is common enough in the commercial world) isn't a problem either.
And "critical mass" as in lots of cool bells and whistles is not as important as stability, ease of use and reliability. Open source projects are not driven by commercial concerns, but by whatever the maintainer of the project thinks is cool and whatever a programmer decides would be fun to implement. You're giving away your time for free - why would you spend it doing boring stuff like fixing hard concurrency bugs instead of adding whizzy cool things ?
That is all fine - I am not saying that open source projects must be driven by commece - but this is a limitation that you need to be aware of when you (in a commercial role) decide to adopt open source tools. Of course, there are many many cases where this all works out fine - Linux itself being one of those.
Now imagine someone pushes a major refactorisation directly onto your working tree, which does not merge cleanly
You deal with that by locking out the destination tree and attempting to apply the merge as an atomic transaction. If it cannot be applied because the user has already begun making modifications, then you abort the transaction and rollback to the point you were at before.
For most commercial organizations, maintaining (including managing change, testing and QA) or their own revision control software is not an option, so having the source code available is not a big selling point. Sure, it's nice to have that flexibility just in case, but in practice it is unlikely you will need it. And to be honest, I really don't give a damn how git works and the less I need to know, the better. My customers don't pay me to be an expert in Git's implementation.
What is more valuable to a commercial organization is the option to pay someone to fix problems when they arise and provide support. If I have a bug that's causing me problems with development, I want to fix it now. Not to have to reassign a team of developers to figure it out.
So I think your argument certainly applies in the open source world, but not for commercial organizations. That's cool - apples and oranges.
That is a fair point - git isn't good for looking at isolated parts or individual files in a repository. But I see it really as a matter of optimizing for the common case. Normally, I need to see the whole repository. Normally I don't need to just look at one file. Git will checkout an entire repository along with all the history faster than SVN will, in the tests that I did.
BTW if I just want to look at one file in Git I use the web interface. That gets around the problem by querying into the main repository.
What you're supposed to do in Git is organize your source code into submodules. This takes very little effort, but you have to do it when you migrate.
SVN does let you check out subdirectories, but that is a strength which is perversely afforded by one of its main limitations. SVN does not track the state of the repository globally. Of course, if you want to track the whole repository state, then you cannot allow people to modify subdirectories independently.
I do typical corporate development, and I don't think centralized repositories are best. I love being able to create my own independent sub-project and ask other developers to contribute to it. What possible reason would there be to not have that functionality ? You do need development and delivery processes to govern where people do work and where it is delivered to, but you'll need those irrespective of which SCM you're using.
You can actually make Clearcase work quite well, without resorting to a baseball bat. The trouble is that you have spend a lot of time and money doing it, substantially more than with any other VCS.
A properly-configured and administrated Clearcase environment is very effective - but not good value for money, IMO. I don't believe there is any other revision control system that can do the build auditing stuff that CC does. Unfortunately, some of the ISO capability maturity model stuff seems to require this. I wonder if any IBM/Rational employees were on the standards boards ..
Well, to use Clearcase properly you have to write a wrapper script that manages and updates the config specs for you. That's the part that they don't tell you when they're selling it to you. Ordinarily, users shouldn't be modifying the config spec.
I love the way when you change the Clearcase config spec and accidentally enter a typo, it doesn't tell you. So you get subtle changes in your repository that you don't expect. I've seen people spend days trying to figure out what was going on when they accidentally modified their config spec with an error.
It's not surprising that developers increasingly favour distributed version control. It's a much more flexible way to work - and if you need to continue working in a centralized way, you can still do that.
If you're migrating to Git, there are a few things you need to account for. Do you want to migrate the history, or make a clean break using the current head of the tree ? Migrating the history is usually hard if it is in a commercial tool, since commercial companies quite obviously do not design their tools to make it easier for you to abandon them (some provide export tools). If you choose not to migrate the history, you have the issue of having to keep the old revision control system around to debug/fix/review older releases.
You need to be clear about your decision. Import some example code into Git (perhaps from your existing repository), put it on a server and ask your developers to play with it to make sure they're happy with the feel and that they're confident they can work with it. Make sure you practice doing things like merging conflicts and merging older maintenance branches. If you do this right, most of your developers should be fairly enthusiastic about the switch when it comes. Make sure you account for Windows users - Git isn't so hot over on Windows and I don't think there is an official stable Windows release yet.
Other than this, there's really very little to it.
I'll pray for your soul. There's nothing worse than a group of managers who think that the world will get better when Clearcase is employed. I swear, that tool seems to be deliberately designed to slow you down.
Git or BK command :
git pull
Clearcase command :
cleartool findmerge -avobs -fversion MYLABEL -merge -gmerge
It may be that a centralized VCS like svn may be a better option.
I cannot conceive of a scenario where this is true. In any case, you can use Git or any other distributed tool as a centralized VCS if you wish. Just tell all your developers to merge their code into the central location, and not to clone from each other's repositories. Dead easy. Although the idea that anyone would seek to make those restrictions makes no sense.
I think it's more popular for one of the same reasons that Bitkeeper initially became popular - it's being used by Linus for the kernel. Getting Linus to use one of your tools is one of the best marketing coups you can land. Outside of this, Bitmover is a small company and it's hard to see how they would have gotten the kind of exposure that they did with the kernel. That said, they seem to be surviving just fine today.
The other reason that it's popular is because it's free. This is fine for open source projects. In the commercial land, managers tend to underestimate the importance of good revision control tools and processes, and the importance of tools which make it easy to build and enforce those processes. Bitkeeper (and some of it's competitors) go to a lot of effort to provide both tools and processes. Git is not so good at this. Other tools that are not good at this include Clearcase (although UCM is an attempt, albeit a controversial one) and CVS.
And I wouldn't say that Bitkeeper and Git are the same. The underlying design concept - distributed version control, changesets, and the benefits that flow out of this eg proper merge tracking and a greater degree of determinism - are the same. Bitkeeper has much better GUI tools, and it's a lot more user-friendly; the command interface is coherent and consistent, and the commands are simpler and easier to remember, options that do similar things are the same across different commands. For example, the "-r" flag always refers to a changeset number, in any command that accepts this parameter. I used BK on a project with between 20 and 45 users; it never once corrupted the repository and there wasn't a single time when the server went down. There were a few times when things were weird when new users unfamiliar with the tool broke their repos, but that stopped after a couple of weeks. The real benefit is that it makes it very easy to see who broke what, and how - whether it was during development or during a merge.
Git isn't friendly or forgiving at all, and you need to really know what you are doing. There are operations that are very dangerous, like the rebase operation; BK does have an equivalent but it incorporates some basic measures to stop someone from messing up the repository they are pushing to.
Additionally, Git will break things in unexpected ways. Try pushing a change into another Git repository, then navigate to that repository and run "git status" - git does not auto-checkout changes in the destination repository during a push. It's the user's responsibility to detect this and deal with it. I find that design approach - the idea that the user is expected to spot and deal with the internal behaviour of the tool - to be pretty bad.
Linus says that anyone who thinks Git is hard to use is an idiot. Idiocy is not the problem here. The developers in the organization I work in do not want to have to know or care about how the internals of the tool work. They want to cut their code, merge it and integrate it as quickly and as effectively as possible. BK easily beats Git on this measure. On the other hand, Git is far and away the superior open-source revision control tool. Anyone who thinks that Subversion is better just doesn't get it.
The c-word is still very much socially unacceptable here (and in the US too - how often to you hear it in movies ? very rarely), so I don't see "git" as a weaker version of it.
I'd put "git" alongside "moron" or "jerk". Nobody's going to raise their eyebrows if you say it.
We should all be working from home.
I find it less efficient if I run my own heating (heating a larger communal space is more cost effective), use my own electricity (offices get bulk rates), and then have to travel into work anyway if I need to meet a customer face to face.
I'm reasonably sure in Europe you could be sued if you refused to carry someone based on their religion or racial background - I have a feeling this is true in the US also ? If so, I hope they take this stupid airline to the cleaners. Even setting the obvious discrimination aside, there was no excuse for denying them travel given that the FBI had cleared them.
The UK doesn't have a written constitution, but it does nonetheless have a means of administration prescribed by parliament - a constitution.
I think this is an oft-repeated misconception. The UK's constitution is written. It's just not all written in one convenient place.
It's interesting how republics like the USA form their own family dynasties, possibly in the absence of an "official" one. Look at some of the senior/well known political clans. Political families (like the Kennedys or the Bushes) are almost unknown in UK politics.
And Americans love the British monarchy. Whenever it was announced that Prince William would be going to the University of St Andrews, the university was beseiged by applications from American teenage women (source), presumably all wanting to marry a likely future king.
That sounds a bit daft to me.
If the untaxed diesel is dyed, then it is straightforward to check if someone has been using it inappropriately by dipping their tank. There's always some dye in there even if the driver subsequently refills with taxed diesel a few times.
If you do it the other way round then you can't easily prove that the driver used undyed diesel ..
Maybe I'm missing something ?
On the Oregon matter, a simple way to protect revenue would be to change the tax so that it's a fixed price per gallon sold, rather than a percentage of the price of the gallon. This way the state always collects the same amount of tax revenue irrespective of the oil price.
The TGV is the result of a number of dynamics in France that aren't so easy to find elsewhere. France suffered a great deal of damage during WW2, and this made it easier to build new railway lines (TGV tracks are long and straight with only the most gradual curves). In addition, they created legislation that effectively ignored objections to the new rail lines being built through people's neighbourhoods. And finally, they assembled a large electricity industry built on nuclear power which provides the energy which powers the trains. I am not sure how easily this can be replicated in other countries.
High speed rail could be done in the US but it would require tremendous political will to face down the lobbyists from the airline industry. I think it could be made to work; surely for business people, an express overnight coast to coast service with sleeping facilities is much more attractive than the current almost full day that would be spent doing the same trip by air.
2)To the whiners who say "We don't have a hydrogen infrastructure" I reply with this: Hydrogen can be produced ANYWHERE there is water and electricity. Every gas station in the civilized world has WATER and ELECTRICITY. All we need to do is drop an electrolysis station in their parking lot. This can be containerized and done with tractor trailers.
And how do we provide the energy to power your portable electrolysis station ?