So as a cmd-line user who only uses centralized repositories (with only a couple of other developers), what kind of benefits would git provide over subversion?
Git would allow you to revert individual commits by other developers. That's something SVN will never be able to do. We just implemented a setup where each developer has his own repository on github, forked from the main repository on github. This makes it very easy for the guy with the final responsibility for deployment to decide which code he accepts and which he doesn't, while everybody else can easily accept whichever commits they like.
This is really useful when some people are committing crazy shit, or some people are working on a big new feature that shouldn't go live yet, while others are working on bugfixes that should go live as soon as possible.
Doing this with SVN is bloody hard. With git it's trivial.
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Git fails because of the lack of integration. Until it has that, it does not fit my needs.
I love IDEs too (although I haven't found one yet that doesn't suck). I admit it would be nice if NetBeans would detect which files have been changed and which have been added (shouldn't be too hard to implement, I think), but beyond that, a command line interface works perfectly fine in combination with an IDE.
What's more, it fails to start with because they didn't consider that in the first place.
Yet people are working on integrating git with IDEs. And let's face it, the Eclipse plugins for SVN aren't all that great either.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits.
Not true. I hadn't even heard of git one month ago, but we just set up a central repository system. Actually we already had a central git repository (on github) before I started working here, but that meant everybody pushed their commits into the same repository, which the guy responsible for deployment to production didn't like: he wanted to keep it stable and only accept changes he approved of.
So now everybody has his own fork on github, pushes commits to his own fork, and the guy merges those forks (branches, basically) back into the main repo. Since merging is trivial, this works out very well. Everybody can access everybody's commits without messing with the stable trunk or making a big mess of things, because git does all the heavy lifting for us.
Having used SVN before, I was very skeptical about git until less than a week ago. Now that I've seen what it can do, I'm a believer.
Git, Bazaar, Mercurial, Darcs and a few other distributed systems are the only ones I've entertained since I lost interest in RCS/CVS years ago. No one in their right mind should be even thinking about so-called tools like SVN these days.
Well, there is one big advantage to SVN: it's possible for mere mortals to understand how it works. To understand git you have to be a fucking genius.
But the awesome magic that git does makes git a worthwhile investment.
Right on the money. Although I'm aware of Git a Eclipse plugin, last time I looked at it, it sucked maturity-wise. Subversion and CVS have been supported on Eclipse
They have, but subclipse is a buggy piece of crap, and while subversive seems better, I still don't trust it the way I trust git. Although it's possible it really is eclipse that's the source of the bugs here. I don't really know about that.
Please expand on this. Are subversion commits not really atomic?
Often when I want to commit a really big change in lots of files (admittedly something you should try to avoid anyway), my SVN GUI fails and I end up having to commit it a few files at a time. But I assume it's the GUI that sucks here.
Most SVN GUIs suck. (But at least they exist, unlike git GUIs, all of which seem incomplete and unusable).
But even if I do commit a lot of files at once, I'm not really sure SVN treats this as a single commit rather than a lot of small commits. Then again, this doesn't matter much in SVN, because you can't revert individual commits anyway.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it?
I do, too. I call it "checking out" and "committing". I do it every few hours.
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
Git makes these things pretty painless.
No matter how good a source control system is at branching and merging, it can't solve the real cost: maintaining a understanding of different, semi-incongruent notions of the project, and then resolving those differences.
No, it can't resolve your personal differences for you, but it can prevent others from polluting your codebase. It can make it easier to undo others' mistakes. Or your own.
The whole point of branching is to increase complexity,
Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it. The problem is that with many source control systems (like SVN) the subsequent merging is complex and often needs to by done by hand. With git, that's not the case.
Despite what a lot of people say, it's actually not true that git makes branching and merging easy. It makes it unavoidable, trivial and painless. It's only in other systems where branching and merging adds complexity.
That's not to say I never branch. But it's always a last resort for me,
Well, with git, it needn't be the last resort. You'll be doing it every day without even noticing.
Clearly, you've never used git to think that some UI can make subversion usable.. Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).
Subversion is perfectly usable if you never ever need to merge a branch back into the trunk.
But even within that limited use case, it still can't do some of the amazing magic that git can do.
Git is an excellent piece of software, but Windows performance is not so great. Git is too UNIX centric to be fast on Windows in the near future.
Speed isn't the only factor when choosing a version control system (or even the most important one), but considering its lightning speed on unix-likes, I wouldn't be all that surprised if git's less-than-brilliant performance on Windows is still faster than SVN.
Javascript was designed specifically to: 1) Have a similar syntax to java
I'm afraid not. Both Java and JavaScript were designed to have syntax similar to C. Java did not exist when Netscape began work on JavaScript. Over time, JavaScript has perhaps evolved to resemble Java more than it used to,
Hardly. The curly brackets are pretty much the only thing they have in common. They're wildly different languages, but some server side implementations of Javascript are able to access Java objects. Which means you suddenly have to worry about whether you're handling a Java String or a Javascript string.
They don't even have the simple classes in common.
When is the press going to realize that Java != Javascript? (Or Java !== Javascript, even!) Comparing "Java" performance between browsers is meaningless. (And isn't what SunSpider does anyway.) Comparing JavaScript performance has a very real impact on the users.
I was surprised about that too. Mozilla was working on a faster javascript engine, and suddenly it's their Java performance (which comes from the JVM, right?) that blows IE out of the water.
Looks like the summary is as bad as the article it tries to summarise.
On a serious note to the OP, I do see version numbers >5 as "has been".
Yet there's still no browser that can beat the performance of Opera 9.xx (where xx = lots).
The first open source CMS my previous employer release was version 6.03 or thereabouts. There'd been a version 5 once (long before I worked there), but I've never even heard of older version numbers.
I assume they existed, though, but they were probably hacked together in javascript or ASP or something, and never amounted to much. Version 6 was the first that made it big, and they're now releasing version 7 which, like every single previous release, is a complete rewrite on a completely new platform. And it's good.
The version numbers represent the history of the company more than the history of the product, I think.
Now, if your research showed there were two products that might do what you want: Foo v1.01 and Bar v6.0. Which one would you choose, based solely on version number?
Based solely on version number? v1.01. It's had a bugfix already, whereas version 6.0 could be a complete code rewrite. At the very least, 6.0 has had some major features added compared to 5.x, and who knows what bugs they have?
Sometimes low version numbers can even be distant descendents of older products wth high version numers. Would you rather have Netscape 4.7 or Firefox 2.0?
Re:the significance of this unusual calm
on
The Quietest Sun
·
· Score: 1
Why is this modded redundant? I thought Sun might have released an unusually quiet Sparc Station.
What exactly are you looking for, as far as creativity goes? Fallout 3, if it is anything like Oblivion, will be a somewhat different experience from what FPS players are accustomed. Calling it "another" shooter seems a little unjust.
One major difference with shooters should be that it's a CRPG, not a shooter, but fans are a bit worried about this one. Another difference is that there's a limited option to pause the game during firefights, but if it's too limited, the game might still end up too shootery.
The things that need to be improved upon aren't as blatantly obvious as they were ten years ago. We've moved from an era of improving the technical standpoint, like graphics and AI, to actually employing them to create an immersive and moving form of media.
I think we've moved from an era of storytelling and fun games to one of showcasing graphics.
Yeah it's less time to wait, but in another way that's almost more frustrating. If there's a long delay you can put it down to localisation, production times, etc., but with only a single day between each region that's clearly not the case - it's like they're deliberately doing it to rub our noses in it that we come last.
No, it's more like it's simply a distribution issue.
I was thinking of halloween.. isnt that when those religious nuts nail people to a cross?
That's when nuts go door to door to ask for candy, while others dress up as scary creatures.
I'm not aware of any holiday where religious nuts nail people to crosses, but Christ was nailed to a cross on Good Friday, a few days before Easter (in spring).
I'm still waiting for Gary Od to come forward and claim copyright for the bible. Its one hell of a work of fiction.. bit boring i'll admit but the ending rocks.
That suggests you've read it, but I don't believe that.
Convincing Slashdot to upmod you for saying "Let's transfer money from video game studios, which we love, to Microsoft, which we hate, because they have hardware problems".
This may have been modded Troll, but this bit is actually quite insightful. If you like the game, it's a lot smarter to pay for the game than for extra hardware.
Did it? I haven't played it yet, but from previews and reviews, my impression is that it's not all that bad, particularly for a Bethesda game. Not as brilliant as FO1&2, but definitely a good buy.
And I just learned that a CD check is all the copyprotection it's going to get, so DRM is no excuse to boycott this game either (although I still intend to get the no-cd patch).
If you're less than ten years away from retiring, then you should have your saving in a simple interest bank account. No stocks. That way a crash won't devalue your money.
This is really good advice (and now that you mention it, my employer's pension adviser told me the exact same thing).
My opinion: when you're young and haven't built up much pension yet, go ahead and put everything in high-risk high-yield stock (especially if the market is low). But when the stock market is booming and it's less than 20 years until you retire, wait until the stock market is really high, or things start to level off a bit, and move everything to somewhere safe, where it won't be hurt by the coming crash. And 10 years before you retire, move it to a safe investment anyway.
The problem is that those sheets of paper are extremely important nowadays. If you have a mortgage, the ownership of your house is regulated by those sheets of paper. If something goes wrong, you suddenly find yourself without a home.
This is really critical, and something that's overlooked. The share market - yeah, whatever. When share prices fall, people who've already started gambling lose some money. That's not the end of the world, by any means.
Even the share market matters to ordinary people. Pensions are often invested in shares (in Netherland they're among the biggest investors). Usually long term in safe, stable shares. Like banks. And when those safe shares drop, normal people, who know nothing about investment and finance, suddenly discover that their pensions aren't worth as much as they used to.
It's a hole that pensions usually climb out of, but retiring just after the crash can really suck.
Slashdot Mirror
So as a cmd-line user who only uses centralized repositories (with only a couple of other developers), what kind of benefits would git provide over subversion?
Git would allow you to revert individual commits by other developers. That's something SVN will never be able to do. We just implemented a setup where each developer has his own repository on github, forked from the main repository on github. This makes it very easy for the guy with the final responsibility for deployment to decide which code he accepts and which he doesn't, while everybody else can easily accept whichever commits they like.
This is really useful when some people are committing crazy shit, or some people are working on a big new feature that shouldn't go live yet, while others are working on bugfixes that should go live as soon as possible.
Doing this with SVN is bloody hard. With git it's trivial.
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Git fails because of the lack of integration. Until it has that, it does not fit my needs.
I love IDEs too (although I haven't found one yet that doesn't suck). I admit it would be nice if NetBeans would detect which files have been changed and which have been added (shouldn't be too hard to implement, I think), but beyond that, a command line interface works perfectly fine in combination with an IDE.
What's more, it fails to start with because they didn't consider that in the first place.
Yet people are working on integrating git with IDEs. And let's face it, the Eclipse plugins for SVN aren't all that great either.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits.
Not true. I hadn't even heard of git one month ago, but we just set up a central repository system. Actually we already had a central git repository (on github) before I started working here, but that meant everybody pushed their commits into the same repository, which the guy responsible for deployment to production didn't like: he wanted to keep it stable and only accept changes he approved of.
So now everybody has his own fork on github, pushes commits to his own fork, and the guy merges those forks (branches, basically) back into the main repo. Since merging is trivial, this works out very well. Everybody can access everybody's commits without messing with the stable trunk or making a big mess of things, because git does all the heavy lifting for us.
Having used SVN before, I was very skeptical about git until less than a week ago. Now that I've seen what it can do, I'm a believer.
Git, Bazaar, Mercurial, Darcs and a few other distributed systems are the only ones I've entertained since I lost interest in RCS/CVS years ago. No one in their right mind should be even thinking about so-called tools like SVN these days.
Well, there is one big advantage to SVN: it's possible for mere mortals to understand how it works. To understand git you have to be a fucking genius.
But the awesome magic that git does makes git a worthwhile investment.
Right on the money. Although I'm aware of Git a Eclipse plugin, last time I looked at it, it sucked maturity-wise. Subversion and CVS have been supported on Eclipse
They have, but subclipse is a buggy piece of crap, and while subversive seems better, I still don't trust it the way I trust git. Although it's possible it really is eclipse that's the source of the bugs here. I don't really know about that.
"commits as _real_ atomic changesets"
Please expand on this. Are subversion commits not really atomic?
Often when I want to commit a really big change in lots of files (admittedly something you should try to avoid anyway), my SVN GUI fails and I end up having to commit it a few files at a time. But I assume it's the GUI that sucks here.
Most SVN GUIs suck. (But at least they exist, unlike git GUIs, all of which seem incomplete and unusable).
But even if I do commit a lot of files at once, I'm not really sure SVN treats this as a single commit rather than a lot of small commits. Then again, this doesn't matter much in SVN, because you can't revert individual commits anyway.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it?
I do, too. I call it "checking out" and "committing". I do it every few hours.
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
Git makes these things pretty painless.
No matter how good a source control system is at branching and merging, it can't solve the real cost: maintaining a understanding of different, semi-incongruent notions of the project, and then resolving those differences.
No, it can't resolve your personal differences for you, but it can prevent others from polluting your codebase. It can make it easier to undo others' mistakes. Or your own.
The whole point of branching is to increase complexity,
Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it. The problem is that with many source control systems (like SVN) the subsequent merging is complex and often needs to by done by hand. With git, that's not the case.
Despite what a lot of people say, it's actually not true that git makes branching and merging easy. It makes it unavoidable, trivial and painless. It's only in other systems where branching and merging adds complexity.
That's not to say I never branch. But it's always a last resort for me,
Well, with git, it needn't be the last resort. You'll be doing it every day without even noticing.
Clearly, you've never used git to think that some UI can make subversion usable.. Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).
Subversion is perfectly usable if you never ever need to merge a branch back into the trunk.
But even within that limited use case, it still can't do some of the amazing magic that git can do.
Git is an excellent piece of software, but Windows performance is not so great. Git is too UNIX centric to be fast on Windows in the near future.
Speed isn't the only factor when choosing a version control system (or even the most important one), but considering its lightning speed on unix-likes, I wouldn't be all that surprised if git's less-than-brilliant performance on Windows is still faster than SVN.
Javascript was designed specifically to: 1) Have a similar syntax to java
I'm afraid not. Both Java and JavaScript were designed to have syntax similar to C. Java did not exist when Netscape began work on JavaScript. Over time, JavaScript has perhaps evolved to resemble Java more than it used to,
Hardly. The curly brackets are pretty much the only thing they have in common. They're wildly different languages, but some server side implementations of Javascript are able to access Java objects. Which means you suddenly have to worry about whether you're handling a Java String or a Javascript string.
They don't even have the simple classes in common.
I hope 3.1 gets out the door soon. FF3 won't work on my mac at all - crashes, bad page renders, missing css, broken javascript.
Really? It works perfectly fine on my macbook.
When is the press going to realize that Java != Javascript? (Or Java !== Javascript, even!) Comparing "Java" performance between browsers is meaningless. (And isn't what SunSpider does anyway.) Comparing JavaScript performance has a very real impact on the users.
I was surprised about that too. Mozilla was working on a faster javascript engine, and suddenly it's their Java performance (which comes from the JVM, right?) that blows IE out of the water.
Looks like the summary is as bad as the article it tries to summarise.
Car manufacturers don't put version numbers of their car as part of their marketing.
Aren't care models usually identified by their year? Like a '69 Mustang or Windows '95?
version numbered software can be very good.
e.g. Inkscape, which is currently 0.46! (stable version).
It's pretty arbitrary when to go to 1.0, 2.0, etc., I would say.
Traditionally, 1.0 is the first actual release. But with open source software, a release is also pretty arbitrary.
On a serious note to the OP, I do see version numbers >5 as "has been".
Yet there's still no browser that can beat the performance of Opera 9.xx (where xx = lots).
The first open source CMS my previous employer release was version 6.03 or thereabouts. There'd been a version 5 once (long before I worked there), but I've never even heard of older version numbers.
I assume they existed, though, but they were probably hacked together in javascript or ASP or something, and never amounted to much. Version 6 was the first that made it big, and they're now releasing version 7 which, like every single previous release, is a complete rewrite on a completely new platform. And it's good.
The version numbers represent the history of the company more than the history of the product, I think.
Now, if your research showed there were two products that might do what you want: Foo v1.01 and Bar v6.0. Which one would you choose, based solely on version number?
Based solely on version number? v1.01. It's had a bugfix already, whereas version 6.0 could be a complete code rewrite. At the very least, 6.0 has had some major features added compared to 5.x, and who knows what bugs they have?
Sometimes low version numbers can even be distant descendents of older products wth high version numers. Would you rather have Netscape 4.7 or Firefox 2.0?
Why is this modded redundant? I thought Sun might have released an unusually quiet Sparc Station.
What exactly are you looking for, as far as creativity goes? Fallout 3, if it is anything like Oblivion, will be a somewhat different experience from what FPS players are accustomed. Calling it "another" shooter seems a little unjust.
One major difference with shooters should be that it's a CRPG, not a shooter, but fans are a bit worried about this one. Another difference is that there's a limited option to pause the game during firefights, but if it's too limited, the game might still end up too shootery.
The things that need to be improved upon aren't as blatantly obvious as they were ten years ago. We've moved from an era of improving the technical standpoint, like graphics and AI, to actually employing them to create an immersive and moving form of media.
I think we've moved from an era of storytelling and fun games to one of showcasing graphics.
Yeah it's less time to wait, but in another way that's almost more frustrating. If there's a long delay you can put it down to localisation, production times, etc., but with only a single day between each region that's clearly not the case - it's like they're deliberately doing it to rub our noses in it that we come last.
No, it's more like it's simply a distribution issue.
Damnit! Then this whole leak was pointless! Ok, what system do you have? We'll get working on it right away!
Could you leak it in a Debian install package?
I was thinking of halloween.. isnt that when those religious nuts nail people to a cross?
That's when nuts go door to door to ask for candy, while others dress up as scary creatures.
I'm not aware of any holiday where religious nuts nail people to crosses, but Christ was nailed to a cross on Good Friday, a few days before Easter (in spring).
I'm still waiting for Gary Od to come forward and claim copyright for the bible. Its one hell of a work of fiction.. bit boring i'll admit but the ending rocks.
That suggests you've read it, but I don't believe that.
Convincing Slashdot to upmod you for saying "Let's transfer money from video game studios, which we love, to Microsoft, which we hate, because they have hardware problems".
This may have been modded Troll, but this bit is actually quite insightful. If you like the game, it's a lot smarter to pay for the game than for extra hardware.
This game turned out to be a disaster.
Did it? I haven't played it yet, but from previews and reviews, my impression is that it's not all that bad, particularly for a Bethesda game. Not as brilliant as FO1&2, but definitely a good buy.
And I just learned that a CD check is all the copyprotection it's going to get, so DRM is no excuse to boycott this game either (although I still intend to get the no-cd patch).
If you're less than ten years away from retiring, then you should have your saving in a simple interest bank account. No stocks. That way a crash won't devalue your money.
This is really good advice (and now that you mention it, my employer's pension adviser told me the exact same thing).
My opinion: when you're young and haven't built up much pension yet, go ahead and put everything in high-risk high-yield stock (especially if the market is low). But when the stock market is booming and it's less than 20 years until you retire, wait until the stock market is really high, or things start to level off a bit, and move everything to somewhere safe, where it won't be hurt by the coming crash. And 10 years before you retire, move it to a safe investment anyway.
This is really critical, and something that's overlooked. The share market - yeah, whatever. When share prices fall, people who've already started gambling lose some money. That's not the end of the world, by any means.
Even the share market matters to ordinary people. Pensions are often invested in shares (in Netherland they're among the biggest investors). Usually long term in safe, stable shares. Like banks. And when those safe shares drop, normal people, who know nothing about investment and finance, suddenly discover that their pensions aren't worth as much as they used to.
It's a hole that pensions usually climb out of, but retiring just after the crash can really suck.