What about the Anti-Ballistic Missile Treaty? The ban on anti-missile missiles was to try to prevent another cold-war type escalation.
Also the Chemical Weapons Convention - US technically signed up, but then said that noone is allowed to actually check due to 'National Security'.
And the Mine Ban Treaty to which the US is the only western country to not sign up (other than Turkey). The trouble with Mines is that millions of them are dropped, and most don't explode during the war, but explode decades after the war.
> I always love the "latest greatest" craze. It's entertaining. People will spend mad money on latest greatest, and I'll wait 6 months or a year to buy the same thing at a fraction of the cost. Maybe I'm part of the problem there. I won't drop $500 on a CPU, but I'll drop $100 on last years model that's only slightly slower.
Say you wait 6 months before upgrading. $400 divided by 6 months = $2 per day. Assuming you earn $20 an hour, if the new chip saved you just 6 minutes per day, then it's a worth while investment to upgrade sooner rather than later.
Despite the flamebait mod, I was hoping to get someone to give me some advantages. Disappoingly the only real 'advantage' that anyone has given so far is that it's more bare-bones and thus forces you to learn learn.
Does Slackware have a real purpose? From the outside, it seems slackware is for people who don't like/understand deb/rpm packages for whatever reason. Are there any other advantages
Given your description, it sounds almost exactly like git svn, except that git svn lets you do all of that locally.
1. Every time I'm going to code a new feature/bug fix, I do it on my own machine first. 2. I check in normally on this local 'branch'. 3. When I'm ready to promote my changes, I first sync down any more recent changes from the trunk. 4. Optionally, I can have someone else look at my branch to do a code read. 5. I 'dcommit' (merge my changes back to trunk).
with additionally
6. I can trivially reorder, squash and edit commits. 7. I can do all of this coding/changing offline. 8. All operations becomes blindingly fast - git log etc is near instant, without hitting the server
Just to nitpick, it does say that sharing of copyright(ed) materials isn't allowed, which shouldn't be correct since Creative Commons work is still copyrighted.
You're only thinking of a single person, not for the whole species.
If you had some event that would wipe out the entire human race and has the same chance as crashing your car, wouldn't that worry you more?
When you are talking about global events, then the level of acceptable risk becomes very low, to the point that you should probably have a clear idea what the risk is before proceeding.
If you want a policy that everything has to be in branches, then you can do that in git. In fact it's much easier in git than svn.
> What it boils down to is that a distributed system allows a developer to go hide in a cave for a while whilst under the illusion that stuff is safely checked in.
With SVN, a developer can go hide in a cave for a while without ever committing stuff. What's the difference?
The part about committing as early as possible doesn't really make sense to me. If you have two group with large changes, then git allows those two groups to merge with each other, making it easy to catch problems _before_ merging with head. That is something SVN just cannot do.
That can backfire. I worked at a large company where they did that. The result is that the whole company still uses RCS. Noone can upgrade because that would break the company policy of everyone using the same thing. And they can't all upgrade at the same time because it's a large company and everyone has different deadlines.
> Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.
How is that different from just copying a developers svn copy? You wouldn't get the history, but you would get the code...
The other things are also possible. See git pre-commit hooks.
Say you offer the repository to the world, so that your users can get your latest work to try it out.
And now you want to do a large refactoring of your code. You could do that as a series of commits locally, test it etc, and then push to the server in one go. Rather than pushing the changes incrementally and leaving the system in a broken state in the mean time.
I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management.
What sort of constraints? Just wondering.
The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.
Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime.
Or you simply don't bother. Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted.
Although with git you can get people to trivially push as a branch to the server (git push origin master:mybranch) which is much more difficult in SVN.
It's pretty much impossible to corrupt git, since every commit is SHA1 checked.
Run: git reflog
and it shows you every change that you made (commits, merges etc). You can then roll back to any point in time. Simply find the magic 6 letter SHA that git reflog gives you for which ever commit you want to go to, then:
git reset --hard SHA
or alternatively:
git reset --hard HEAD@6
to mean to rollback as it was 6 changes ago (it makes more sense when you see the output from git reflog)
> A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution.
I work in a large scale commercial development team and we use git. I still see no possible advantage of SVN over git from that structural point of view.
The plugins and clients for git will grow rapidly I'm sure.
The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.
Copying code between repository sounds like a bad idea to begin with - it means that you are losing the history of the files.
Also the temporary experimental folders should be done with branches. Unfortunately any centralised system sucks at doing branches, compared to git or mercurial.
Honestly, I think you should spend a few hours learning svn, and then get "git svn" and learn and use that.
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Notice that they put the qualifier "It's believed". As in, some people believe that. They don't even commit themselves to a "We believe" let alone taking the huge leap of faith of just "The new technology will cost more",
Slashdot Mirror
What about the Anti-Ballistic Missile Treaty? The ban on anti-missile missiles was to try to prevent another cold-war type escalation.
Also the Chemical Weapons Convention - US technically signed up, but then said that noone is allowed to actually check due to 'National Security'.
And the Mine Ban Treaty to which the US is the only western country to not sign up (other than Turkey). The trouble with Mines is that millions of them are dropped, and most don't explode during the war, but explode decades after the war.
> I always love the "latest greatest" craze. It's entertaining. People will spend mad money on latest greatest, and I'll wait 6 months or a year to buy the same thing at a fraction of the cost. Maybe I'm part of the problem there. I won't drop $500 on a CPU, but I'll drop $100 on last years model that's only slightly slower.
Say you wait 6 months before upgrading. $400 divided by 6 months = $2 per day.
Assuming you earn $20 an hour, if the new chip saved you just 6 minutes per day, then it's a worth while investment to upgrade sooner rather than later.
BTW, I did something similar using custard powder (Which is basically just cornstarch + colouring) and it worked just as well.
Just put custard powder in a bowl then add a small amount of water. It's great fun to play with.
Despite the flamebait mod, I was hoping to get someone to give me some advantages. Disappoingly the only real 'advantage' that anyone has given so far is that it's more bare-bones and thus forces you to learn learn.
Does Slackware have a real purpose? From the outside, it seems slackware is for people who don't like/understand deb/rpm packages for whatever reason. Are there any other advantages
Given your description, it sounds almost exactly like git svn, except that git svn lets you do all of that locally.
1. Every time I'm going to code a new feature/bug fix, I do it on my own machine first.
2. I check in normally on this local 'branch'.
3. When I'm ready to promote my changes, I first sync down any more recent changes from the trunk.
4. Optionally, I can have someone else look at my branch to do a code read.
5. I 'dcommit' (merge my changes back to trunk).
with additionally
6. I can trivially reorder, squash and edit commits.
7. I can do all of this coding/changing offline.
8. All operations becomes blindingly fast - git log etc is near instant, without hitting the server
etc.
Just to nitpick, it does say that sharing of copyright(ed) materials isn't allowed, which shouldn't be correct since Creative Commons work is still copyrighted.
Why use this instead of git svn?
You're only thinking of a single person, not for the whole species.
If you had some event that would wipe out the entire human race and has the same chance as crashing your car, wouldn't that worry you more?
When you are talking about global events, then the level of acceptable risk becomes very low, to the point that you should probably have a clear idea what the risk is before proceeding.
Wow, your place of work sucks. Seriously - forced to commit every 2 hours? Wow.
If you want a policy that everything has to be in branches, then you can do that in git. In fact it's much easier in git than svn.
> What it boils down to is that a distributed system allows a developer to go hide in a cave for a while whilst under the illusion that stuff is safely checked in.
With SVN, a developer can go hide in a cave for a while without ever committing stuff. What's the difference?
The part about committing as early as possible doesn't really make sense to me. If you have two group with large changes, then git allows those two groups to merge with each other, making it easy to catch problems _before_ merging with head.
That is something SVN just cannot do.
That can backfire. I worked at a large company where they did that. The result is that the whole company still uses RCS. Noone can upgrade because that would break the company policy of everyone using the same thing. And they can't all upgrade at the same time because it's a large company and everyone has different deadlines.
git doesn't work well in that sort of scenario.
Where I work, the artists use SVN and the developers use Git.
> Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.
How is that different from just copying a developers svn copy? You wouldn't get the history, but you would get the code...
The other things are also possible. See git pre-commit hooks.
Say you offer the repository to the world, so that your users can get your latest work to try it out.
And now you want to do a large refactoring of your code. You could do that as a series of commits locally, test it etc, and then push to the server in one go. Rather than pushing the changes incrementally and leaving the system in a broken state in the mean time.
I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management.
What sort of constraints? Just wondering.
Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime.
Or you simply don't bother. Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted.
Although with git you can get people to trivially push as a branch to the server (git push origin master:mybranch) which is much more difficult in SVN.
It's pretty much impossible to corrupt git, since every commit is SHA1 checked.
Run: git reflog
and it shows you every change that you made (commits, merges etc). You can then roll back to any point in time. Simply find the magic 6 letter SHA that git reflog gives you for which ever commit you want to go to, then:
git reset --hard SHA
or alternatively:
git reset --hard HEAD@6
to mean to rollback as it was 6 changes ago (it makes more sense when you see the output from git reflog)
(--hard will delete any uncommitted changes)
You can even undo your undos etc.
KDE is also currently moving to git. Currently Amarok and a few other KDE apps have switched first, to iron out any bugs.
> A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution.
I work in a large scale commercial development team and we use git. I still see no possible advantage of SVN over git from that structural point of view.
The plugins and clients for git will grow rapidly I'm sure.
The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.
Copying code between repository sounds like a bad idea to begin with - it means that you are losing the history of the files.
Also the temporary experimental folders should be done with branches. Unfortunately any centralised system sucks at doing branches, compared to git or mercurial.
Honestly, I think you should spend a few hours learning svn, and then get "git svn" and learn and use that.
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Ah the sound and fury of an internet tough guy, signifying nothing.
No, Mr AC, when the robot is ready, it won't need to dodge bullets.
It could just catch them :)
Notice that they put the qualifier "It's believed". As in, some people believe that. They don't even commit themselves to a "We believe" let alone taking the huge leap of faith of just "The new technology will cost more",
The monopoly part is that Google is now legally allowed to display out-of-print works, but other companies are not.
The license is for _only_ Google.