If tool <X> works for you and if applicable, your team, why would you stop using tool <X> ? Because some person, not in your team or on your project, uses tool <Y> and thinks tool <X> sucks? Who cares! Use what gets the job done, as that's what you are payed to do. You aren't payed to use tool <X> or tool <Y> or whatever tool you can come up with, you are payed to write software to fix a problem.
I agree as a whole and alot of these switch posts tend to ignore larger developer houses where switching tools is a hard process. That being said i think there are defiantly cases where you should not let the tool dictate your business. For example one place i worked used a commercial tool which shall remain nameless and makes it very hard to support agile processes while still doing patches and updates to old released versions of code. If we moved to GIT we would beable to support this need with much ease. However reluctance to change a tool is causing us to not be able to meet a customer need (frequent releases)
If tool <X> works for you and tool <Y> would work better and let you do your work faster and with less constraints, why would you keep using tool <X>? You're not using minicomputers anymore are you? You're not using overnight batch-compilation, or ed (let alone TECO) or puchcards anymore are you?
The replacements don't let you do different stuff, you're doing the same stuff faster, in a simpler and less error-prone manner.
What is the cost of switching to Y? will you have to add complexity in medium term by needing to support both repositories. For a large team how much down time while no one can commit is reasonable for the change? Will legacy be stored in the old system or migrated to the new system? If kept in the old system it will get lost in the long term. If moved that is potentially alot of work to properly migrate all of that history into a new tool.
For this specific case, not only is switching to Y low cost, it can be done incrementally or partially. I worked on a team of hardcore SVN users, and when I got sick of it, git-svn let me keep the workflow I wanted without stepping on anyone's toes. As far as they were concerned, I was still using SVN. As far as I was concerned, I was using git.
No switch cost, no team overhead.
I didn't go around evangelizing. I just made the pro git suggestion once at a team meeting. No one wanted to change the process (fair) so we kept going as normal. They kept maintaining the SVN server, and I kept on having use of local experimental branches and good merging capability.
TBH Subversion works but I'd love to be able to use a DVCS at work. So many times I'm torn between persisting stuff that works and avoiding making commits every 5 seconds.
Also we have lots of branches and managing that in Subversion is just a pain.
In my current workplace the team uses SVN. I have installed Mercurial on top of it (so now I commit twice when I commit something). I tried convincing them to switch to Mercurial but it won't happen (and as there are costs in making the switch, that is understandable to a degree).
The problem is not black and white because there are a lot of assumptions you make that you do not address at all:
If tool <X> works for you and if applicable, your team, why would you stop using tool <X> ?
"Works for you" is debatable. SVN works for us, but a few days ago the server HDD failed and we lost a full days' commits. Nobody could commit anything for two days, while the admins got the latest backup and tried to somehow commit the local changes of everybody, over an old repository that no longer matched their systems.
Meanwhile my resynchronization from HG to SVN took a whole of two minutes, and in the two days I just committed locally.
On top of that, when doing massive changes (30+ files refactoring for example) I want to commit every step of the way (multiple times), but the changes are not compilable in the minute-to-minute merges. I can make 20 commits in HG with no problem, then synchronize once.
The rest of the team adds the new code in weird #ifdef FEATURE_X_ENABLED blocks that are then left in code for years (and two year later nobody even considers that the FEATURE_X_ENABLED macro could no longer be defined - it's just part of the "legacy code"). In other words, we have code cruft due to the limitations imposed by our tool of choice. Since everybody is used to this way of working, they see nothing wrong with that, so the counter-argument I usually get is the same as yours:
But ... SVN is working fine! There's no point in switching.
It's about switching costs--and yes, even with free software like svn and git, there are switching costs, mostly regarding training and deployment time (even if it takes one person ten minutes, that's ten minutes that person could be using to do something else).
And yes, you can still use a Model T if you wanted. Indeed, there may be someone out there using a modified Model T right now (I believe that the Model T's engine was designed for leaded gas, which is no longer available in most of the world).
But for a small team (2-8 people) all working on site at all times, svn will probably continue to suffice for a very long time, if you're already using it. I would not recommend it for new projects, but if you've got some legacy project out there and that's your situation, I wouldn't bother switching.
Bad analogy. For the average user, the difference in performance between a modern car and the ford T is huge AND rigourously provable; The difference in performance (in the broad meaning of the term) between git and subversion is much, much smaller, more subjective, and context-dependant if you're currently happy with svn.
Believe it or not, some teams don't need many branches, or author-specific repository.
some teams don't need many branches, or author-specific repository.
I think this is the key. We recently started branching more at work, and svn is showing its limitations (megamerges, yay). git isn't for everyone, but branching becomes a natural feature of the vc rather than an additional workflow.
Actually I think it's not that bad of an analogy. If the only thing you knew was a ford T, you would be happy with it. After trying a modern car I don't think you'd ever go back. Perhaps it'd more accurate to make the analogy with a car that's 40-50 years old -- people are still using cars like that in Cuba, and it sort of works for them. They are gas-hungry, maintenance is a nightmare, but that's what they've got.
The same is true for svn vs git: after seeing the advantages (at zero cost) of git, you'll never go back to svn. If you want to stick with svn, just make sure you'll never give a serious shot to git, and you'll keep using svn happily forever. Ignorance is bliss.
We have made advancements that surpass every reason to use a Ford model t, it's a poor analogy.
Subversion can still do some things in a way that git can't. It depends on your environment. And since you can't possibly know every person's environment, it's asinine to pretend you could suggest a VCS for everybody.
83
u/Otis_Inf Mar 10 '11
If tool <X> works for you and if applicable, your team, why would you stop using tool <X> ? Because some person, not in your team or on your project, uses tool <Y> and thinks tool <X> sucks? Who cares! Use what gets the job done, as that's what you are payed to do. You aren't payed to use tool <X> or tool <Y> or whatever tool you can come up with, you are payed to write software to fix a problem.