I would suggest using git for two reasons: 1. It's in far wider use so you (and your fellow developers) will be gaining knowledge that is more likely to be useful. 2. GitHub
If you are in small-to-medium size organization, github's paid plans are a tremendous value. In fact, I would go so far as to say that, for these companies, maintaining your own source code repo server is akin to heating your office by burning American currency. Granted, some organizations have issues (valid or otherwise) with hosting their code outside their own network. YMMV. Things to watch out for: - Visual Studio is extremely annoying when working with a source control system such as git. I don't use any plugins personally. It's nearly a cliche wrapped in a meme by now, but the command-line is powerful enough that you don't need a gui *once you have learned how to use it*. Make sure that you have someone on the team that is experienced enough with DVCS to help people that get stuck. If you're bringing git to your team, you might want to take a few weeks to get very familiar with it in so you can take that role. - Skeptics. Sometimes there are people that will simply refuse to learn and will jump on any problems as justification of their anti-change attitude. This is one reason to have at least one "git helper" ready to deal with issues. - SVN/CVS/TFS command-line users. Some of git's commands (checkout, add, reset, fetch) do things that are unexpected if you are coming from a server-based source control background. While I don't use a visual tool for interacting with git, I _do_ use one (gitx on OSX or git gui on windows) to view the repository. When helping someone learn git, refresh the gui after _every_ command to see what changed. You can also do this in a terminal by running git log --graph --decorate --all --oneline. (Which prints out a graphical representation of the git commit tree, similar to the gui tools). Good luck Dave On Dec 10, 2010, at 8:37 AM, Justin Rudd wrote: > 1.) Is impossible to answer objectively. There are no git visual studio > plugins so using either from Visual Studio is completely dependent on which > one you like better. For me, it is bazaar because its rename support is > truly rename (not a remove than add), and it supports versioning directories > (which I have found quite handy). But if I was picking between git and > mercurial, I'd use mercurial but only because I have more experience with > Mercurial than git and I find it works better with Windows (git works fine > with Windows just not as cleanly in my opinion). > > 2.) Nope. But I tried VisualHg (http://visualhg.codeplex.com/). And it > pretty nice. I don't know if all the features are solid, but the "hidden" > ones that I used (rename files, rename directories, etc.) worked without me > having to drop to the command line to fix things up before commit. > > 3.) I don't know about git, but with Mercurial securing access to the > repository was hit or miss. We served up the central repository behind an > IIS box. We put ACLs on the repo and sometimes they worked, sometimes they > didn't. Never really debugged it to a root cause... > > On Fri, Dec 10, 2010 at 8:10 AM, Shawn Neal <[email protected]> wrote: > TFS and it's nanny checkout system has annoyed me for the last time, so I was > hoping to solicit some feedback from other's who might have moved away from > centralized revision control system to a DRCS like Git or Mercurial. Our > development team has experience with both Git and Hg, but for non .NET > development. I worry about how well these two play with Visual Studio; I > suspect without some sort of VS integration it'll be harder to use than TFS > especially for renames. > For .NET development with VS 2010, which works better, Git or Hg? Why? > Do you use any source control plugins to VS? Which one? > When moving from a centralized version control system to a distributed one, > what are some things to watch out for? > Thanks in advance, > -Shawn > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
