On Sun, May 23, 2010 at 4:52 PM, Andrew Sayers <andrew-git@xxxxxxxxxxxxxxx> wrote: > 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. EGit do not work with git-svn, it probably work just fine with "pure" git tough. I've seen TortoiseGit, it work very well but I found it somewhat more difficult then the command line: probably because I don't know where to find the command i daily use on git. I extensively use git grep and probably there isn't anything like it in TortoiseGit. > 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. Yes, that's why I'd like to skip git-svn and go directly with git, unless I know the people I'm teaching to can handle it. > 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. Yeah, there is one developer tired of Subversion that asked me to teach him git(-svn). He's not in my team but I think it's a starting point :) > 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. Probably it will be a svn-like architecture from the beginning, I'll not dare to move it any further until I know that developers are ready to handle it properly :) I'm not sure myself I can manage a workflow different from subversion (1 main server and N developers pushing to it) because I never did anything different. > 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. I did not know about this.. That's really interesting, I just enabled it in my local repo. Thanks for the hint! > 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. Sysadmins shouldn't be a problem, we don't have sysadmins here and if the custumer require us to use his own versioning system we can't push them to git, so I think that wouldn't be a proble for us. But that's a good point. > 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. Thanks, I'll keep that in mind when I'll face the big switch. > 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). Thanks about the book suggestion, I'll give them both a try! Regards, Daniele Segato -- 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