Hi Daniele, I agree that a lead developer moving a team from graphical SVN is a different problem. I don't think git-gui does SVN, I couldn't work out how to make TortioseGit work with SVN, and I doubt EGit will like SVN very much. You're also right that git-svn has limitations with merging and rebasing. Specifically, don't use them unless you know what you're doing - see `man git-svn` for more. Git-svn is also less newbie-friendly than either git or svn on its own. Having said that, I'd still recommend you try moving a few developers to git during the lifetime of your current project. In my experience, those developers most willing to try something new in the middle of a project are also the ones that want to get hacking right away on a new project. Getting even one developer to start migrating now will be good practice for you, and will double the number of eyeballs looking at git issues later on. Slowing down for less than a week is a very ambitious target - I think we had about 2 weeks of noticeably reduced productivity, even when I'd done a lot of work to spread the pain over several months. Starting git with a new project might reduce that time a bit - for example, there's no chance of uncommitted work in an SVN checkout failing to make the switch. But it can be more expensive in the long-run, because you have to make all of your architectural decisions based on what you can explain to SVN users on day one - for example, my team took about 2-3 weeks to understand how a commit is different from a push, and why they should care. But because they understood before we made the big leap, we were able decentralise our workflow as much as we needed. If you do go via git-svn, I'd recommend you read `man git-rerere` and set the config option "rerere.enabled" to "true" for all users. I needed to blow away a few messy merges to fix rookie mistakes, and `git-rerere` would have made a painful experience much easier. Even if you go straight into git, you might think about finding/writing hooks to synchronise an SVN repository and a git repository. There will probably be a few people you can't switch right away - e.g. a sysadmin that would need months to rewrite all his scripts, or a designer that doesn't want to learn a different tool just for your team. Providing a semi-functional legacy interface for those people will let you raise the pressure on them more gradually. I forgot to mention education in my previous post, which was actually one of the biggest problems during the move. I was surprised how everyone had such different learning styles - some wanted to learn the theory then be left alone, some wanted to be told each solution at the moment they faced the problem, some wanted to learn by watching how I worked, etc. The only real pattern seems to be that the busier people are, the more they like to feel they're pulling information out of you, and the less receptive they are when you push information at them. I muddled through by trying to give everyone more of whatever they each reacted best to. The biggest problem I had with teaching git to SVN users was something I still have difficulty putting into words. SVN users focus on branches as the centre of their development history, and see commits as these funny little things that punctuate the progress of their branches. But git users focus on commits (or even trees) as the centre of their history, and see branches as one of many handy labels that track them. The distinction is subtle, but it affects a lot of the expectations people have. For example, SVN users like to think of a commit as being "on a branch", meaning that it marks an event in the lifetime of one SVN directory. To this day, I don't think I've really communicated why you can only say a git commit is "reachable from the tip of zero or more branches". Because my team needed time to unlearn a lot of these SVN issues, I didn't try to push much deep git tech at them early on. A few months into the move though, it's starting to seem like a better idea. One of my team-mates got me to start reading "Version Control with Git" (http://oreilly.com/catalog/9780596520137) - from what I've seen so far, I'd definitely recommend it to people that like book-learning and are ready to learn git without bringing their old SVN baggage. On the other hand, you can cobble the same information together from various online sources if you prefer (http://book.git-scm.com/ is a personal favourite). - Andrew Sayers -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html