1. Sergey Antonov
  2. HgSccPackage
Issue #78 invalid

Not modify the project files after adding solution to scc

Juan Francisco Miranda Aguilar
created an issue

Would it be possible letting the project files untouched after adding the solution to SCC, instead of adding this tags

  • <SccProjectName>
  • <SccLocalPath>
  • <SccAuxPath>
  • <SccProvider>

to them??

It's a bit annoying the task of removing this tags manually if you have to change the SCC for the solution.

Comments (10)

  1. Sergey Antonov repo owner

    This is configurable in the HgSccPackage settings.

    • Open the MSVS
    • Go to menu Mercurial -> Options -> Main
    • Remove check mark for "Use Scc bindings in projects and solutions"

    After that HgSccPackage will not add a Scc binding to a project/sln files when you use "Add to Source Control" command.

    You can also add/remove Scc bindings to an existing project/sln files using a Mercurial -> Change Scc Bindings command.

  2. Juan Francisco Miranda Aguilar reporter

    Thanks for your help, but if I do this way, does the plugin detect if the project is controlled with Hg and automatically changes the source control provider like the git plugin does? I opened some projects, and it doesn't, I have to change it manually.

  3. Sergey Antonov repo owner

    Nope. That is the whole point of using Scc bindings.

    Without a Scc binding in the project there is no way for MS Visual Studio to load a correct source code control provider.

    When MS Visual Studio loads a project and sees a Scc bindings it uses SccProvider string to load a registered source code control provider for that project.

    Some plugins tries to use some hacks to outsmart VS, but those are generally doesn't work.

  4. mla89

    I also removed the check mark for "Use Scc bindings in projects and solutions" because our team decided that scc bindings should NOT be saved in Sln/Proj-Files. It is no problem to change the source control plug-in to HgSccPackage (since I use an other extension that automatically changes to the right scc plug-in).

    BUT with the removed check mark, I have to manually click "Add To Source Control" for EACH Project in the HgSccPackage toolbar EVERYTIME I reopen the solution, in order to get the scc plug-in work correctly (e.g. status refresh in the solution explorer and other toolbar features are not working). Can you fix this??

  5. Sergey Antonov repo owner

    Scc bindings are used by Visual Studio to AUTOMATICALY load the correct Source Code Control provider when loading a solution/project without additional extensions.

    If you are not using the Scc bindings and the HgSccPackage is not the current Source Code Control provider in Visual Studio at a time when you load a project, then you have to select it manually. You can do that in Tools -> Options -> Source Control -> Plugin selection -> Current Source Control Plugin. There is no need to Add To Source Control EVERY time.

  6. mla89

    Thanks for your quick response. The problem is that some features of HgSccPackage don't seem to work, although HgSccPackage is already selected as current Source Code Control provider when I load a project/solution in VS.

    The scenario:

    • Solution and project Scc Bindings are both unbound
    • Solution is inside a mercurial repository
    • HgSccPackage is selected as current Source Code Control provider (manually)
    • Solution is loaded

    The following picture shows VS when I am now editing and saving a file: Capture.PNG

    As you can see, status refresh in the solution explorer doesn't work and some toolbar buttons are greyed out..

    With the "Add To Source Control" button I can fix this for one project, but the next time I load the solution, there is the same problem.

    (In Settings check mark "Use Scc bindings in projects and solutions" is removed)

  7. Sergey Antonov repo owner

    Thanks for a steps to reproduce, you are right there was indeed a bug.

    I do not use this setup (withous Scc bindings) myself, so I've missed this case.

    I've made a quick fix v2.0.1.1 for this bug (attached to this issue), it should work now.

  8. Log in to comment