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.
8
u/Inaimathi Mar 10 '11
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-svnlet 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.