I suggest you ...

Ability to configure Source Control settings per project

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Currently, The source control settings can be set per windows user.So if I'm working on different projects and each one has it's own Source Control (VSS,TFS,Tortoise...etc), then every time I want to open one of the project, I have to go and change VS source control settings to meet the source control that is being used for the project...

This is a time consuming and causes a frustration for me.

Vote please :)

1,648 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Anas Ghanem shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

This is a great idea! We completely understand how auto-switching SCC providers would help increase your productivity. Although we plan to make this available to you in the near future, we are still in the planning process and may reach out for your feedback as we start to define how tackle this problem. We will check back as soon as possible with any updates to this request. Allison Buchholtz-Au: VS Program Manager ​​


Sign in
Password icon
Signed in as (Sign out)
  • Cameron Angus commented  ·   ·  Flag as inappropriate

    Quite amusing reading through the comments going back several years, and further still on other sites. I'll vote, but it seems like it's just pointless...

  • Michael Stokes commented  ·   ·  Flag as inappropriate

    Please fix this. It is annoying to have to change the source control. when I use TFS for one project then all the VS git projects are set to Microsoft GIT Provider. Then I have to change it to GIT Source Control Provider for every VS project I open (I have 4).

  • Raul Planas commented  ·   ·  Flag as inappropriate

    Per project is great but also one for solution as well. (Solution file needs to be stored somewhere.)

    I work across multiple source control providers as well. We typically structure though each solution to only be a single source control provider. Build systems will then copy output of our SDK solutions to a repository for other solutions to reference. Currently in process of moving these SDK solution outputs to our own hosted Nuget respository.

    In this cases a per-solution source-control setting would be sufficient. But allowing a per-project override of solution would be agreeable.

  • Roger Hendriks commented  ·   ·  Flag as inappropriate

    You have 3 votes left! >> [Vote] 3 >> You have run out of votes on this forum? >> 3 votes left!

  • Roger Hendriks commented  ·   ·  Flag as inappropriate

    I use 3 different systems so this is quite a pita. And as we are all techs we know that is is VERY VERY EASY to develop. I guess 4 hours if you are a very slom developer? 1 extra XML tag in the sln file and voila.

  • Derrick Glass commented  ·   ·  Flag as inappropriate

    I work as a contractor/consultant and may have to switch between lots of projects in the course of a single day. Often, just back and forth between the same two for a while. It is annoying to have to manually switch the source control provider; we can work around this with a custom VSPackage but it seems like a per-project override (I wouldn't mind a global default) would be straightforward and match actual usage more closely.

  • Craig E. Shea commented  ·   ·  Flag as inappropriate

    I whole-heartedly agree. I think a common scenario would be your company, for whatever reason, uses TFS VC. You want to "try something out", which isn't so easy to do with TFS VC, unlike Git, where you can just create a branch at any time with very low cost. Unfortunately, this means changing the source code control provider in _the IDE_. Why at the IDE level? That doesn't make sense for a lot of reasons already mentioned: many people write code on projects spanning different VCS systems (e.g. legacy apps in VSS or TFS while newer ones are in Git or Mergurial). So everytime they open a new IDE, there's a 50% chance (or more, depending on the number of VCS's in use) that the VSSCC will need to be changed. Ugh..

  • Philip Lonsing commented  ·   ·  Flag as inappropriate

    Actually using different source control systems on one machine is not uncommon.
    For example: Use one system company wide and another for open source projects on github.

  • Anonymous commented  ·   ·  Flag as inappropriate

    2015 and we can't do this yet... wow. This is required at the PROJECT level, think abut shared assets across distributed teams.

  • Anas Ghanem commented  ·   ·  Flag as inappropriate

    Thanks for your comment, I really tried to edit before but the only option available is to delete it !!

  • Todd Morrow commented  ·   ·  Flag as inappropriate

    Hi Anas, please edit your request to support multiple VCS in the same solution. It's really not just a one to one relationship on the solution level, it can be one solution associated with many version control providers. For example, when contractors don't have access to a clients internal VCS, so they use something like GitHub, but the client may have to keep GitHub and their internal VCS up to date. If they are going to take the time to fix this, let them fix it right. Thanks!

  • Rob commented  ·   ·  Flag as inappropriate

    Yes, in the modern world, having multiple source control solutions is hardly surprising.

  • Kelvin Nguyen commented  ·   ·  Flag as inappropriate

    Why this has not been built yet? This is supposed to be one of "most advanced" IDE out there right ?

  • Micha K. commented  ·   ·  Flag as inappropriate

    Yes! This is a musthave for me. That's not the expected behavior for the highest integrated IDE, isn't it? I like to configure my source control per solution.

Feedback and Knowledge Base