3 ms·
Because it works for the people who are doing the work. Many outsiders have suggested that they switch, but that advice never seems to take hold.
by Gracana 10y ago
Because it works for the people who are doing the work. Many outsiders have suggested that they switch, but that advice never seems to take hold.
- int_19h 10y agoThere are a lot of things that "work". If you need to edit files, "ed" works to edit files, for example. But if someone was using that outside of scripts today, I think it's not unreasonable to ask why. The question is, why, knowing that there are things that work vastly better (I'm not speaking hypothetically here - I used CVS for many years myself, and I remember all the painful limitations, and the nearly universal joy on the team when we finally migrated to Subversion), they still stick to that old stuff? Sure, there's some cost to migration, but it's been done thousands of times before by other people, so there are a lot of tools that automate all that, and vast knowledge about how to do it right. So the cost really low compared to the objective benefits that they would get - such as, well, being able to rename things without wiping history, or tracking changes across several files etc. So, is it really just the "that's how we did that in the good old days, and that's how we like it - now get off my lawn" sort of thing, or are there some technical reasons why they consider CVS good enough? I'm hesitant to assume the former until I can definitely ascertain that it's not the latter.
- IcePic 10y agoWell, your ed comparison could aswell be made for vi -vs- emacs (or Eclipse spit). As long as the code being written is entered as fast as someone can type on the keyboard, it really doesn't matter which editor they use. Sure, vim and emacs and bloaty-stuff-in-java can help in various ways, but since they aren't really writing the code for you, if the limit is how fast you can write the code, the amount of java or elisp or vim-scripts around your text editor won't have a large impact on how good network code or how safe your string handling is. I won't argue that the opposite is true, but the general speed limit in openbsd is not the tooling or even the meta-tooling around the source tree, but rather how many decent coders is active at this moment and how much useful code can they get reviewed and committed. I don't think I've ever seen something along the lines of "phew, if I hadn't had $weird-dvcs in place, I could not have invented this provably correct parallel AVX-accelerated version of SHA768" or something to that effect.
- int_19h 10y agoBut it isn't vim vs Emacs, that's the whole point! If we were talking about two different apps with comparable feature sets, at least for common operations, sure. But CVS is really vastly inferior even to Subversion, to which e.g. FreeBSD migrated 7 years ago. Just to make it clear, I'm not complaining about OpenBSD using CVS in general, or claiming that they are too slow or missing features because of it. I'm just wondering why, in this day and age, anyone would use CVS when so many clearly better alternatives exist. I know I would be frustrated if I had to code in a CVS repo, and would push to get it migrated to at least SVN just to make my own life more comfortable. So it naturally makes me wonder why other people in that situation, who presumably know at least as much as me, do not.
- IcePic 10y agoI think the reason is that the versioning tooling is 1% of the work, so making it 0.5% would not be "twice as effective", it would move from 100% to 99.5% work to be an openbsd dev. Diffs mailed between devs still look the same, oks for diffs are still a social construct that needs persons and not programs.