Subversion will use less space on indivual developer's computers disks.
I've heard git is pretty bad about disk space, but Subversion is a bit ridiculous in it's own right. With SVN you are storing the working copy twice: once for the files you will work on, and again as a backup copy so svn can do diffs.
In mercurial the repository is heavily compressed and revisions are stored as diffs (with occasional full copies) so this is a non-issue if you don't have a lot of binary data. If you're going to use that much disk space with svn, you may as well go with mercurial and have the entire repository history while you're at it.
Using a central server will give you an obvious place to go to for a system of record.
You can synchronize on a central repository using git, mercurial or bazaar. The difference is that you have the choice of when to push your changes upstream, and you have the option to continue working and performing commits locally when you are offline.
Using a central server will let you check user ids based on an external authentication system to make sure you can blame the right person when they break the software.
This is all possible with distributed repositories too.
You don't use branching that much and can safely ignore the dumbest decision ever on the part of the subversion developers
I'm not sure what the "dumbest decision" you're referring to is. But I don't blame you if you don't use branching with CVS or SVN--branching is easy, but merging branches is horrid. The is due mainly to the fact that neither CVS nor SVN knows when a particular commit represents a merge from another branch of development. So you have to either merge from the branch point, or research the commit history to determine when the last time the two branches were merged--otherwise you'll have a major mess on your hands trying to merge two branches with many duplicate changes.
With a distributed VCS this is not a problem. git, mercurial and bazaar all keep track of how you merge different changesets together so that a merge only as complicated as the actual changes make it, not how complicated your VCS tool makes it.
For example, let's say you release version 3.0 of your software. You tag the changeset as "v3.0" and continue on work for 3.1.
hg tag v3.0
Now suppose that a week later, a security flaw is discovered which must be patched immediately. You update your working copy to the "v3.0" tag, and start a branch "3.0_maintenance". You make the changes and commit them to the 3.0_maintenance branch.
hg update -r v3.0
hg branch 3.0_maintenance
// make the required changes in code
hg commit -m "Security fix see bug 19237"
You want your ongoing development on 3.1 to include the bug fix you just committed to 3.0, so you switch back to the default branch, merge the changes from 3.0_maintenance, and commit.
Later, when another bug is discovered in 3.0, this same process will suffice to patch the 3.0_maintenance branch and to merge the change back into the default branch.
Who's the idiot that keeps tagging everything "suddenoutbreakofcommonsense?" It was cute once or twice; now it makes me want to murder cute little furry animals.
The US for instance is currently ruled by representatives of Big Oil and private military corporations that are sucking trillions out of the hands of the US taxpayers. With that kind of money available its no wonder there is corruption abounding. When the Iraq war winds up, you can expect another one to follow because the companies making all that money at the moment will not be likely to stand for a peace. Its too good a racket
Let me explain to you how this works. You see, the corporations finance Team America. And then Team America goes out and the corporations sit there in their, ih in their corporation buildings and, and and see that's, they're all corporationy, and they make money. Mhm.
we were told that *theoretically* the twin towers could withstand airplanes crashing into them.
They didn't. *Theoretically* my spaghetti is defective, because I cannot use it to build a ladder.
Slashdot Mirror
We didn't listen!
Joey, do you like movies about gladiators?
Ceeeeeelebrate good Obama, come on!
..It's Obam-Obama!
I'm Vistacapable, you insensitive clod!
Hmm... I expect his body was hidden in the last place they looked. It always seems to work out that way for me.
It is customary to stop searching for something after you've found it.
The eighties wanted them back.
They want their joke back too.
I've heard git is pretty bad about disk space, but Subversion is a bit ridiculous in it's own right. With SVN you are storing the working copy twice: once for the files you will work on, and again as a backup copy so svn can do diffs.
In mercurial the repository is heavily compressed and revisions are stored as diffs (with occasional full copies) so this is a non-issue if you don't have a lot of binary data. If you're going to use that much disk space with svn, you may as well go with mercurial and have the entire repository history while you're at it.
You can synchronize on a central repository using git, mercurial or bazaar. The difference is that you have the choice of when to push your changes upstream, and you have the option to continue working and performing commits locally when you are offline.
This is all possible with distributed repositories too.
You don't use branching that much and can safely ignore the dumbest decision ever on the part of the subversion developers
I'm not sure what the "dumbest decision" you're referring to is. But I don't blame you if you don't use branching with CVS or SVN--branching is easy, but merging branches is horrid. The is due mainly to the fact that neither CVS nor SVN knows when a particular commit represents a merge from another branch of development. So you have to either merge from the branch point, or research the commit history to determine when the last time the two branches were merged--otherwise you'll have a major mess on your hands trying to merge two branches with many duplicate changes.
With a distributed VCS this is not a problem. git, mercurial and bazaar all keep track of how you merge different changesets together so that a merge only as complicated as the actual changes make it, not how complicated your VCS tool makes it.
For example, let's say you release version 3.0 of your software. You tag the changeset as "v3.0" and continue on work for 3.1.
Now suppose that a week later, a security flaw is discovered which must be patched immediately. You update your working copy to the "v3.0" tag, and start a branch "3.0_maintenance". You make the changes and commit them to the 3.0_maintenance branch.
You want your ongoing development on 3.1 to include the bug fix you just committed to 3.0, so you switch back to the default branch, merge the changes from 3.0_maintenance, and commit.
Later, when another bug is discovered in 3.0, this same process will suffice to patch the 3.0_maintenance branch and to merge the change back into the default branch.
Mercurial (or git, or bazaar) kept track of not only the branch points but the merge points for you, which makes merging simple like it should be.
Contrast this with CVS or SVN where you have to track dow
Now your vote didn't matter.
Let me explain it to you: you have tab A, and tab B.
Sorry, I was distracted by something shiny.
Could you restate your scenario in terms of tab A and slot B?
Who's the idiot that keeps tagging everything "suddenoutbreakofcommonsense?" It was cute once or twice; now it makes me want to murder cute little furry animals.
Slashdot Idle is shaping up to be the new Mandatory Fun Day.
The US for instance is currently ruled by representatives of Big Oil and private military corporations that are sucking trillions out of the hands of the US taxpayers. With that kind of money available its no wonder there is corruption abounding. When the Iraq war winds up, you can expect another one to follow because the companies making all that money at the moment will not be likely to stand for a peace. Its too good a racket
Let me explain to you how this works. You see, the corporations finance Team America. And then Team America goes out and the corporations sit there in their, ih in their corporation buildings and, and and see that's, they're all corporationy, and they make money. Mhm.
Cooking is actually an advanced version of chemistry.
In my kitchen, cooking is a form of alchemy:
Yeah. He looks totally different without his glasses. You can't even recognize him.
That doesn't make any sense! He wouldn't be able to see.
[citation needed]
The CEO did say that, should anything happen to LGP, he and all of his dev team are authorized to distribute patches which remove the check.
Dear Mr. CEO:Just in case anything should happen to you or your devs, perhaps you should give me that patch now. Just in case. I promise I'll keep it safe.
Three or more, it's research.
Legitimate research differs from your implication in that sources are given credit through citations. Whhhhhhoooooooooooosh!How about "suddenoutbreakofpithytags" instead?
Please tag responsibly.
Please tag responsibly.
Please tag responsibly.
suddenoutbreakofpithytags
The S is a broadcast flag intended to forbid unauthorized reproduction. You are all in violation and will be fined infinity billion dollars.
In my neighborhood you can get free trash removal by putting up a sign stating "Free (or best offer)."