3 ms·

> This is a false assumption and a flawed comparison. An SSD has the same external interface as a spindle disk. It does have does have different internal proper

by felipec 15y ago

> This is a false assumption and a flawed comparison. An SSD has the same external interface as a spindle disk. It does have does have different internal properties though that make it superior in almost all use cases though. Wrong. If SSDs are superior in every way, why do spin disks still exist? Because SSDs are way more expensive for the same size, and don't have as much storage. And you are ignoring the point by focusing on SSDs and not the point being made. > I actually have to admit that after reading the whole comment thread in your blog, I'm actually convinced that the HG folks won the argument. Oh really? Can you point to the comment in which they answer to my challenge? Or do you feel that evidence is not important? > However, my answer to your question is a different one: Different tasks require different tools. Limiting yourself to one tool based on one use case is not a good decision. Fallacy of hasty generalization. Sometimes it's better to pick the tool depending on the job, sometimes you should specialize in a certain tool. For example, there's not much point in picking a different editor for different tasks. A more succinct example is saying; limiting to one tool, your hands, is not a good decision. Well, you can use your feet for some tasks if you want, the rest of the world would prefer hands any time for most tasks. > For example: Have you ever tried teaching non-developers (i.E. designers) the full git user interface with all it's powers? I usually get about as far a the subset that's equivalent to what svn can do before they nod me off. Have you? And were they already familiar with SVN? That's the problem, you are not even aware you are making an assumption; that SVN is the natural way to to SCM, and thus mercurial's UI is good because it resembles SVN. As I mentioned in my blog post; some people claim they find git easier to learn, particularly the ones that don't know SVN, or were tainted by crap like CVS. IOW; they don't relearn.

Xylakant 15y ago
> Wrong. If SSDs are superior in every way, why do spin disks still exist? Because SSDs are way more expensive for the same size, and don't have as much storage. And you are ignoring the point by focusing on SSDs and not the point being made. Well, I guess we're running in circles. My point was: I can swap a spindle disk of the same size with an ssd of the same size and reap all the benefits without changing anything beyond that. You can't swap tools that use different (if similar) underlying concepts in that way. (That's still oversimplifying in the case of disk.) > Oh really? Can you point to the comment in which they answer to my challenge? Or do you feel that evidence is not important? Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you. It's a bit like vi vs emacs. Both are certainly capable and do have demonstrable advantages over the other but in the end it's a matter of which feature matters most to you. > A more succinct example is saying; limiting to one tool, your hands, is not a good decision. Well, you can use your feet for some tasks if you want, the rest of the world would prefer hands any time for most tasks. Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision. Well, you can always use a hammer for some screws, but the rest of the world would prefer using a screwdriver for most screws." My point is not "pick the least fitting tool for any task you find." but rather "have a sledgehammer and a carpenters hammer ready." You don't want the sledgehammer to hang up a picture, but you'd not want the carpenters hammer to drive in a pole either. > Have you? And were they already familiar with SVN? That's the problem, you are not even aware you are making an assumption; that SVN is the natural way to to SCM, and thus mercurial's UI is good because it resembles SVN. Yes I have. Multiple times. And some were familiar with svn and some where not. However, nowhere did I say that they preferred hg over git nor am I making any assumption that there even exists something such akin to a natural way to do SCM. I argue that for their use cases the feature set of what svn can do is wholly sufficient. They don't do branching and they don't do merging since PSD files merge so awfully bad even with git. The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move. They want mandatory locking in the repository for their word files so that person A can indicate "hey, I'm working on that document". And I hope we can agree that for the set of features that is supported by svn, svn offers the simpler mental model and also the simpler user interface. It does away with all that local repository and only knows a local working copy and a centralized remote storage. You can push changes to the remote and pull updates from there. And if that's all you ever need, svn might be the natural choice. Or maybe perforce. Or alienbrain. If your uses go beyond that, well, then it isn't. And then it's maybe git. Or darcs - which does have some very nifty features of it's own. As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not. Example: git uses the sometimes the full verb (git add, commit, ...) and sometimes an abbreviation (git rm). This probably stems from the fact that "rm" is the unix command to remove files and in line with what the usual unix developer would expect, but it's not internally consistent. HG always uses the full verb (hg add, hg remove). Git knows (add, remove, move) but not (copy). Git knows "git submodule add" which is a simple operation but the reverse is an arcane invocation that requires you to modify two config files and may as well trash your repository if executed wrong. None of this is related to svn or the svn user interface.
- felipec 15y ago
  > My point was: I can swap a spindle disk of the same size with an ssd of the same size and reap all the benefits without changing anything beyond that. And what does that point has to do with anything? > Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you. Wrong. It's not a judgement call, I mentioned specifically for which cases git branching is superior, and I constructed a challenge to show that git is superior in that case and NOBODY answered the challenge. Conversely, NOBODY provided a case for the opposite; that mercurial's branching is superior in any case. It's very simple; you can do more with git branching than with mercurial branching. Period. > Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision. Completely irrelevant. You can't get out of the hasty generalization fallacy by pointing out a case in your favor. Yes, sometimes proficiency in more tools is better, but not ALWAYS. Just like yeah, in some cases black people like chicken, but not ALWAYS. > The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move. Assumptions, assumptions, assumptions. > As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not. There have been calls for suggestions for improvement, including radical changes since years. NOBODY has ever suggested to replace 'rm' with 'remove'; it's not an issue. If you want to talk about real consistency issues, how about branches vs bookmarks vs anonymous branches. In git they are all branches.

by felipec 15y ago

Xylakant 15y ago

> Wrong. If SSDs are superior in every way, why do spin disks still exist? Because SSDs are way more expensive for the same size, and don't have as much storage. And you are ignoring the point by focusing on SSDs and not the point being made. Well, I guess we're running in circles. My point was: I can swap a spindle disk of the same size with an ssd of the same size and reap all the benefits without changing anything beyond that. You can't swap tools that use different (if similar) underlying concepts in that way. (That's still oversimplifying in the case of disk.) > Oh really? Can you point to the comment in which they answer to my challenge? Or do you feel that evidence is not important? Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you. It's a bit like vi vs emacs. Both are certainly capable and do have demonstrable advantages over the other but in the end it's a matter of which feature matters most to you. > A more succinct example is saying; limiting to one tool, your hands, is not a good decision. Well, you can use your feet for some tasks if you want, the rest of the world would prefer hands any time for most tasks. Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision. Well, you can always use a hammer for some screws, but the rest of the world would prefer using a screwdriver for most screws." My point is not "pick the least fitting tool for any task you find." but rather "have a sledgehammer and a carpenters hammer ready." You don't want the sledgehammer to hang up a picture, but you'd not want the carpenters hammer to drive in a pole either. > Have you? And were they already familiar with SVN? That's the problem, you are not even aware you are making an assumption; that SVN is the natural way to to SCM, and thus mercurial's UI is good because it resembles SVN. Yes I have. Multiple times. And some were familiar with svn and some where not. However, nowhere did I say that they preferred hg over git nor am I making any assumption that there even exists something such akin to a natural way to do SCM. I argue that for their use cases the feature set of what svn can do is wholly sufficient. They don't do branching and they don't do merging since PSD files merge so awfully bad even with git. The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move. They want mandatory locking in the repository for their word files so that person A can indicate "hey, I'm working on that document". And I hope we can agree that for the set of features that is supported by svn, svn offers the simpler mental model and also the simpler user interface. It does away with all that local repository and only knows a local working copy and a centralized remote storage. You can push changes to the remote and pull updates from there. And if that's all you ever need, svn might be the natural choice. Or maybe perforce. Or alienbrain. If your uses go beyond that, well, then it isn't. And then it's maybe git. Or darcs - which does have some very nifty features of it's own. As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not. Example: git uses the sometimes the full verb (git add, commit, ...) and sometimes an abbreviation (git rm). This probably stems from the fact that "rm" is the unix command to remove files and in line with what the usual unix developer would expect, but it's not internally consistent. HG always uses the full verb (hg add, hg remove). Git knows (add, remove, move) but not (copy). Git knows "git submodule add" which is a simple operation but the reverse is an arcane invocation that requires you to modify two config files and may as well trash your repository if executed wrong. None of this is related to svn or the svn user interface.

felipec 15y ago
> My point was: I can swap a spindle disk of the same size with an ssd of the same size and reap all the benefits without changing anything beyond that. And what does that point has to do with anything? > Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you. Wrong. It's not a judgement call, I mentioned specifically for which cases git branching is superior, and I constructed a challenge to show that git is superior in that case and NOBODY answered the challenge. Conversely, NOBODY provided a case for the opposite; that mercurial's branching is superior in any case. It's very simple; you can do more with git branching than with mercurial branching. Period. > Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision. Completely irrelevant. You can't get out of the hasty generalization fallacy by pointing out a case in your favor. Yes, sometimes proficiency in more tools is better, but not ALWAYS. Just like yeah, in some cases black people like chicken, but not ALWAYS. > The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move. Assumptions, assumptions, assumptions. > As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not. There have been calls for suggestions for improvement, including radical changes since years. NOBODY has ever suggested to replace 'rm' with 'remove'; it's not an issue. If you want to talk about real consistency issues, how about branches vs bookmarks vs anonymous branches. In git they are all branches.