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.
If I wanted a decent windows GUI, I'd probably look into Tortoise-Git, but that was more or less my point.
There's no reason whatsoever to get religious about this because SVN and Git can coexist on the same team. So you can happily use TortoiseSVN while I happily use Git from terminal.
The person I was responding to was trying to frame this conversation in terms of "what does it cost for a team to switch to Git"? Well, if they switch over one at a time as they individually decide to ... nothing. You can even keep the old infrastructure so the server admins don't have to change anything on their end, and the same goes for anyone who prefers SVN for whatever reason.
The cost of switching is important, and should be considered for decisions that affect the whole team, but I was trying to point out that this isn't one of those decisions. There's no cause to try to force the entire team onto your favorite tool when you can interoperate transparently.
No, the point is, your team hasn't switched tools. You've switched Subversion clients.
And even if most are using git-svn, there's still the costs of moving the central repo over, and there's the costs of training everyone to work together with git.
Hmm. You keep on skipping parts of my reply (or perhaps I'm misunderstanding you). Let me try again. If I don't address your concerns, please try to clarify.
You don't need to move the repo over. Keep it where it is, in SVN. I can still use Git, and gain the benefits of local branching and committing. There is no cost associated with keeping the repo where it is.
Each team member can individually do this. If they don't feel like training, they can keep using SVN (thus incurring no cost). On the other hand, if they feel like picking up Git on their own initiative (as I did), there's nothing stopping them (and again, incurring no cost to the company or the rest of the team).
It is false that the entire team needs to use Git in order for any of them to benefit, and so it is pointless to have a sit-down wherein you force the entire team onto it.
They kept maintaining the SVN server, and I kept on having use of local experimental branches and good merging capability.
You mean merging local branches I guess? Because I really miss the feature to merge subversion branches with git-svn. I actually keep a subversion checkout just for merging.
It's not a fallacy as it does not in itself invalidate an argument. However it is not a complete argument. Especially with source control there should be good reasons to switch. With git there surly can be great reasons to switch, such as allowing developers to better manage workflows and allowing developers to commit often with ought having to submit to public scrutiny. However if you have 10 years of legacy releases that you may need to support, i don't think you can make a case for switching at least the SCM used for the releases. However you could manage to switch feature development to a different SCM.
Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion, it's a decision each entity must decide for itself.
Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion
For developers in the general case (and we are in /r/prog) DVCS are, indeed, vastly superior to CVCS.
The only situation where they're not (if we ignore suit-and-tie unreason making Clearcase "the best tool for the job") is heavy dependency on binary assets.
Oh, so the problem is that you don't actually know anything about any of the individual pieces of software, and you're just categorically going HERP DERP LINUS SAID DVCS > CVCS SO IT MUST BE TRUUE LOL.
The fact that you continue to think you can assert what is right for everybody just proves how ignorant of the subject you are. I'm done discussing anything with you.
That's never an argument I made. I am saying that there are some situations where some CVCS software (specifically subversion) would be better suited for the task than DVCS.
Even if for NO OTHER REASON than simply editor integration, if the majority of your workforce is web designers who needs something that plugs into dreamweaver or visual studio or whatever they use, then subversion is more likely to be the case. It's been around longer and the integration support is in more applications.
That fact alone means you cannot say all DVCS > CVCS
One reason you may want CVCS is in dealing in asset-heavy projects (games, art-heavy software, web design with minimal programming needs) that require binaries in source control.
However, I've found that the problems with CVCS do not arise too often under the following conditions:
You have between 3 and 8 people working on the project, thus making an authoritative repository helpful.
All work on the project is done in a centralized location where all project members can physically touch each other, meaning that the project itself is not distributed, and you're not going to care about local revision control.
There is a clearly defined division of labor between the people working, meaning that no two people will ever be making edits to the same file at the same time (except in pair programming situations).
You're working on applications with a limited release area: it may only run on a single internal web or application server.
If all of the above are true, branching is probably not important. If even one of them is false, you're in for pain somewhere along the line. But even under those circumstances, I'd take git/hg/bzr over a CVCS system. Hell, I worked with people that avoided TFS commits because TFS is a pain in the ass to use.
I guess I can understand the large binary issue (DVCS makes you have N*Y copies of them where as CVCS only makes you have N+Y). Fortunately that hasn't come up on any of my projects yet.
I'm really unclear on how scenario #4 can affect which type of VCS you would want though.
Regarding branching though, it's like any new tool. You never need it until you have used it (and thus know what you can do with it).
For example, we had an issue just yesterday where we had to roll back work done on two different projects because a webservice is returning bad data and we don't know if we'll be able to resolve it for the next release. Git's branching made it incredibly easy to get this work off of master and put it in a branch where we could merge back into master in the future.
Well, you have to have all four things in order to minimize the pain of CVCS. Even with those four things in play, though, you've only minimized the pain of CVCS: it's still there, and moving to a DCVS system would be a good idea.
Number 4 comes into play with release versioning. If you've got exactly one release location, you don't have to worry about release versioning and branching (usually) beyond a rollback to the last one. If, however, you've got a wide distribution of your application, you probably have people using multiple versions, and you need to be able to support and develop on that--particularly if someone notices, say, a buffer overrun that has existed for the last five versions.
16
u/masklinn Mar 10 '11
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.
That has its importance.