81–90 of 112 posts
Earlier quoted context omitted.
Not if he put equal amounts of effort into learning git, svn and hg.
If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.
Earlier quoted context omitted.
Whereas with a simpler tool like subversion, there will be no tight spots.
Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use. Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'. In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit…
Regardless, you can rollback changes in subversion without bungling future merges.
Earlier quoted context omitted.
Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use. Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'. In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit…
Being able to disappear/discard history has significant downsides, too. Regardless, you can rollback changes in subversion without bungling future merges.
Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate.
So no malicious data loss possible, but an agreed-upon cleanup is.
Nb., in SVN only a central repo holds the full history. Should the admin remove some changeset, there's no way to check, or prove, that it ever was there. That is a (formal, legal etc) problem in certain situations. With Git, once you've fetched a changeset, it's there, all yours (till you explicitly remove it).
In SVN, should a malicious blackhat break in and add backdoor to code in a central repo, noone will notice. In Git, correctness and consistency is ensured courtesy of SHA1.
In Git and in SVN you can alter history. In Git, it's either `everybody agrees' or `somebody notices something went haywire because changeset chain doesn't match'. In SVN, it's `I trust the central repo with everything, fingers crossed'.
Earlier quoted context omitted.
Being able to disappear/discard history has significant downsides, too. Regardless, you can rollback changes in subversion without bungling future merges.
> Being able to disappear/discard history has significant downsides, too. Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. So no malicious data loss possible, but an agreed-upon cleanup is. Nb., in SVN only a central repo holds the full history. Should the admin remove some chan…
These features also make it very easy to make mistakes with your own local repository, and propagate those mistakes upstream (even if they can then be detected and resolved), which was the original poster's point, as I recall.
> In SVN, it's `I trust the central repo with everything, fingers crossed'.
In reality, this isn't an issue for organizations, and decentralization introduces a considerable amount of complexity that confuses most users. Businesses already rely on the correctness of centralized resources and have straight-forward processes to monitor and maintain them -- be it accounting data, a centralized CA, their corporate directory and payroll system, or SCM.
Ignoring the fact that this level of validation largely unnecessary -- if I were going to modify subversion to institute better validation of data, I would implement PKI signing of commits, not decentralization of the repository. Git has some support for this, but honestly this is not very high on the list of most organization's priorities, and largely only matters more for open source projects, if at all.
Earlier quoted context omitted.
> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine". It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oo…
But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage." > We sometimes even actively try to deny others the very powers we refused to take. Huh? Who was that directed at?
Earlier quoted context omitted.
> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo w…
It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.
Earlier quoted context omitted.
> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine". It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oo…
You use words and phrases such as "poisonous meme", "should be fought tooth and nail", "demonstrably better in every way for every foreseeable usage", "dominates"... Strong words. I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.
Earlier quoted context omitted.
> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine". It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oo…
But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage." > We sometimes even actively try to deny others the very powers we refused to take. Huh? Who was that directed at?
I didn't say that. I actually agree with that.
My other point was more general.
Earlier quoted context omitted.
If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.
What do you mean by 'sane', and how does subversion (which includes merge tracking) fail to meet your definition?
http://stackoverflow.com/questions/2475831/merging-hg-git-vs...