I'm currently working on .Net projects that are using either Git or Mercurial (Hg) source controls. I use Visual Studio 2010 for all of these projects. As I often have to switch source control providers I was wondering if there's a quick way to do this, so I don't have to go Tools -> Options -> Source Control once an hour.
A much better solution would be if Visual Studio would recognize which source control provider it needs or maybe remember which provider was used for a certain project. Can that be done?
With a nudge in the right direction I managed to handle this problem even better then expected - no switching necessary.
For Mercurial solutions I use VisualHG and for Git I use Git Source Control Provider. I also installed HgSccPackage. Now I don't really know how or why this works, but I've got GitSCC selected as the Source Control Provider in the settings, but when I load a Mercurial project VisualHG takes over. All I have to do is set the SCC to VisualHG the first time I open the project, close the project, change back to GitSCC and when the project is reloaded VisualHG will be used for it.
Interestingly it does not work without HgSccPackage installed. If someone can explain this, please do.
Note that it does not seem to work the other way round.
I use Git in combination with VS 2010 by keeping a commandline screen open. I do my work in Visual Studio and when I'm ready to make a commit, I switch to the commandline screen.
If you do this, you can use Git and Mercurial side by side in combination with VS 2010.
Related
I have an annoying problem with source control plugins... I'm using VS2012 and I have some projects on TFS and others on SVN (using AnkhSVN).
When I open a SVN solution, VS seamlessly switches to AnkhSVN as the source control plugin, which is fine. But then, when I open a TFS solution, it doesn't switch back to TFS... the most annoying effect is that automatic checkout doesn't work. To fix it, I have to unload the solution, changes the source control plugin to TFS, and reload the solution.
Is this a known problem? Is there a way to fix it?
There is not a good option that I can think of. That part of Visual Studio is designed to work only with one Source Control system at a time and I understand your pain.
I guess my first question is why you need both, but I guess there is some need somewhere. You can see folks with the same problem:
How to quickly switch source control providers in Visual Studio 2010?
Option 1: Virtualisation
As I have a machine capable of running VM's (Windows 8 with Hyper-V) I would have two VM's with one configured for TFS and the other configured for SVN. Not elegant, but it would allow you to switch.
Option 2: Regedit
You can change the setting in the registry.
HOW TO: Change Source Control Providers If Two or More MSSCCI-Compliant Providers Are Installed
So you could have a "key" file for each setting stored on your desktop and:
Close Visual Studio
Run registery key
Open Solution
While ugly and requires remembering it would be the best option locally.
Conclusion
There is no good answer but I do think that the two options above will get you there.
Is there a way to tell Visual Studio 2005 to just ignore source control binding when opening a solution? I sometimes need to load a solution for which I don't have access to the source control server, but Visual Studio insists on trying to connect anyway, meaning I have to click "temporarily work offline in disconnected mode" for every project in the solution (of which there are about 20) as it loads. For some reason, it also tries to check each project out immediately after I've told it to work offline, so I have to click past that dialog box too.
As I will never need to edit anything in this solution, is there any way I can open it and have Visual Studio just ignore the fact it has source control bindings in it?
Edit: Ideally, I'd like a way to do this without having to change the project/solution files. They change fairly frequently, so I'd have to redo any changes every time there was a new version (otherwise I'd just unbind them once and it wouldn't be a problem).
Thanks for the replies so far.
The source control bindings are stored in Visual Studio solution file (.sln). For TFS for example, it contains a global section for TFS information and the solution projects added to TFS. You can edit the solution file to remove these bindings manually. I would suggest making a copy of the solution file first. However, I would recommend removing bindins via Visual Studio. Open your solution and go through the offline scenario. Then go to File/Source Control/Change Source Control (VS 2008) to bring up the UI that shows you the source control bindings in your solution. There you can manage the bindings including unbinding them. Once unbound, the next time you open the solution, VS should not have a need to access the source control.
I've been looking for a way to disable Integration between SourceSafe 2005 and Visual Studio 2008. We are forced to use SourceSafe being in a corporate environment and all. SourceSafe is fine on its own if you treat it like a baby. As soon as you try to do anything approaching useful it starts to break. God forbid you try to use the integration with Visual Studio. Being that I didn't want the "Bindings removed" so that it doesn't confuse other devs on the team I needed to be able to tell Studio to ignore the solution and project bindings and continue on it's merry way.
I followed the registry hack suggested in the following post
Removing SourceSafe Integration from Visual Studio 6
Studio did what I wanted...sort of. It removed the SourceSafe integration. However when I opened up a source controlled solution it asked me if I wanted to remove the bindings.
"the projects will be treated as not under source control"
No I don't want you to remove the bindings from the files, I want you to IGNORE them. This dialog pops up every time you open the solution/project file and there is no way around it.
My solution at the moment seems to have worked...for now.
File->Source Control->Change Source Control...->Disconnect
I hope this helps anyone else in the position of having to use SourceSafe but can't remove the bindings from the files themselves. WHY, Microsoft, WHY would you put the bindings in the files themselves?
/rant
I'd like to try out a feature of AnkhSVN (namely, integration with Red Gate SQL Changeset tool) without doing an complete uninstall of VisualSVN. It feels dodgy, so I wanted to see if anyone else had experience that would either alleviate or confirm my fears.
Update
So I tried uninstalling VisualSVN and dropping in Ankh. As far as working within VSS itself, the change was completely transparent. Sadly, SQLChangeset did not work with this plugin, so that part of it was in vain.
Switching back was also painless, even to the point of not having to re-enter my license. So, good knowledge but no joy on the long-term goal.
Sort of. I've been able to install VisualSVN and AnkhSVN on Visual Studio at the same time. However, you won't be able to use both at the same time. VisualSVN is an add-in, while AnkhSVN is truly a source control plugin. To use one or the other, you simply have to disable source control binding (for AnkhSVN) or disable the plugin (for VisualSVN).
In my experience, though, I've found that VisualSVN was a much better client than AnkhSVN. VisualSVN handles ignoring user files (*.suo) and adding projects to Subversion very efficiently. AnkhSVN on the other hand, caused me some difficulty.
Hope this helps!
I haven't tried it, but I know Visual Studio supports multiple source control plugins. You just pick which one is active from the options by choosing Tools->Options from the menu and then finding the Source Control->Plug-in Selection page in the tree control on the left side of the window that opens.
It should just be a matter of installing Ankh and selecting it there for your tests, then setting back to VisualSVN when done. Of course, that assumes everything plays nice together.
You might be able to turn off / disable VisualSvn in Tools -> Addin Manager, and then select AnkhSvn as the current SCC Provider.
Can you describe how this changeset tool works, and how that should integrate with AnkhSvn?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As a long-time Visual SourceSafe user (and hater) I was discussing switching to SVN with a colleague; he suggested using Git instead. Since, apparently, it can be used as peer-to-peer without a central server (we are a 3-developer team).
I have not been able to find anything about tools that integrate Git with Visual Studio, though - does such a thing exist?
What are the technologies available for using Git with Visual Studio? And what do I need to know about how they differ before I begin?
In Jan 2013, Microsoft announced that they are adding full Git support into all their ALM products. They have published a plugin for Visual Studio 2012 that adds Git source control integration.
Alternatively, there is a project called Git Extensions that includes add-ins for Visual Studio 2005, 2008, 2010 and 2012, as well as Windows Explorer integration. It's regularly updated and having used it on a couple of projects, I've found it very useful.
Another option is Git Source Control Provider.
I use Git with Visual Studio for my port of Protocol Buffers to C#. I don't use the GUI - I just keep a command line open as well as Visual Studio.
For the most part it's fine - the only problem is when you want to rename a file. Both Git and Visual Studio would rather that they were the one to rename it. I think that renaming it in Visual Studio is the way to go though - just be careful what you do at the Git side afterwards. Although this has been a bit of a pain in the past, I've heard that it actually should be pretty seamless on the Git side, because it can notice that the contents will be mostly the same. (Not entirely the same, usually - you tend to rename a file when you're renaming the class, IME.)
But basically - yes, it works fine. I'm a Git newbie, but I can get it to do everything I need it to. Make sure you have a git ignore file for bin and obj, and *.user.
Git Source Control Provider is new plug-in that integrates Git with Visual Studio.
I've looked into this a bit at work (both with Subversion and Git). Visual Studio actually has a source control integration API to allow you to integrate third-party source control solutions into Visual Studio. However, most folks don't bother with it for a couple of reasons.
The first is that the API pretty much assumes you are using a locked-checkout workflow. There are a lot of hooks in it that are either way expensive to implement, or just flat out make no sense when you are using the more modern edit-merge workflow.
The second (which is related) is that when you are using the edit-merge workflow that both Subversion and Git encourage, you don't really need Visual Studio integration. The main killer thing about SourceSafe's integration with Visual Studio is that you (and the editor) can tell at a glance which files you own, which must be checked out before you can edit, and which you cannot check out even if you want to. Then it can help you do whatever revision-control voodoo you need to do when you want to edit a file. None of that is even part of a typical Git workflow.
When you are using Git (or SVN typically), your revision-control interactions all take place either before your development session, or after it (once you have everything working and tested). At that point it really isn't too much of a pain to use a different tool. You aren't constantly having to switch back and forth.
I find that Git, working on whole trees as it does, benefits less from IDE integration than source control tools that are either file based or follow a checkout-edit-commit pattern. Of course there are instances when it can be nice to click on a button to do some history examination, but I don't miss that very much.
The real must-do is to get your .gitignore file full of the things that shouldn't be in a shared repository. Mine generally contain (amongst other stuff) the following:
*.vcproj.*.user
*.ncb
*.aps
*.suo
but this is heavily C++ biased with little or no use of any class wizard style functionality.
My usage pattern is something like the following.
Code, code, code in Visual Studio.
When happy (sensible intermediate point to commit code, switch to Git, stage changes and review diffs. If anything's obviously wrong switch back to Visual Studio and fix, otherwise commit.
Any merge, branch, rebase or other fancy SCM stuff is easy to do in Git from the command prompt. Visual Studio is normally fairly happy with things changing under it, although it can sometimes need to reload some projects if you've altered the project files significantly.
I find that the usefulness of Git outweighs any minor inconvenience of not having full IDE integration but it is, to some extent, a matter of taste.
Microsoft announced Git for Visual studio 2012 (update 2) recently. I have not played around with it yet, but this video looks promising.
Here is a quick tutorial on how to use Git from Visual Studio 2012.
Also don't miss TortoiseGit...
https://tortoisegit.org/
There's a Visual Studio Tools for Git by Microsoft. It only supports Visual Studio 2012 (update 2) though.
Visual Studio 2013 natively supports Git.
See the official announcement.
The Git support done by Microsoft in Visual Studio is just good enough for basic work (commit/fetch/merge and push). My advice is just to avoid it...
I highly prefer GitExtensions (or in less proportion SourceTree). Because seeing the DAG is for me really important to understand how Git works. And you are a lot more aware of what the other contributors to your project have done!
In Visual Studio, you can't quickly see the diff between files or commit, nor (add to the index) and commit only part of modifications. Browse your history is not good either... All that ending in a painful experience!
And, for example, GitExtensions is bundled with interesting plugins: background fetch, GitFlow,... and now, continuous integration!
For the users of Visual Studio 2015, Git is taking shape if you install the GitHub extension. But an external tool is still better ;-)
TortoiseGit has matured and I recommend it especially if you have used TortoiseSVN.
The newest release of Git Extensions supports Visual Studio 2010 now (along with Visual Studio 2008 and Visual Studio 2005).
I found it to be fairly easy to use with Visual Studio 2008 and the interface seems to be the same in Visual Studio 2010.
The simplest solution that actually works quite well is to add the TortoiseGit commands as external tools.
Solution to adding a Git (TortoiseGit) toolbar to Visual Studio
As mantioned by Jon Rimmer, you can use GitExtensions. GitExtensions does work in Visual Studio 2005 and Visual Studio 2008, it also does work in Visual Studio 2010 if you manually copy and config the .Addin file.
Currently there are 2 options for Git Source Control in Visual Studio (2010 and 12):
Git Source Control Provider
Microsoft Git Provider
I have tried both and have found 1st one to be more mature, and has more features. For instance it plays nicely with both tortoise git and git extensions, and even exposed their features.
Note: Whichever extension you use, make sure that you enable it from Tools -> Options -> Source control -> Plugin Selection for it to work.
As of 2013-02-11, the Microsoft Git plugin for Visual Studio 2012 should work with the Express version as well.
My company is using Visual SourceSafe (VSS) and Visual Studio 2005 (soon 2008). They want to switch to CVS, but the developers don't want to lose the integration we get with VSS and Visual Studio.
I know there are CVS plugins, but what functionality, if any, is lost with CVS?
If you're going to switch, why not switch to something better? CVS is a long way from state of the art in version control. A more modern system like Subversion or Vault not only offers better features, but it will get you better Visual Studio integration as well.
Screaming at VSS for lost source code, etc. Seriously though, it is a very different model (optimistic locking), so you will probably lose some productivity for the first little while. I would probably look at using TortoiseCVS and "Open Folder In Windows Explorer" right-click or the Visual Studio Explorer plug-in rather than a CVS plug-in if you are using Visual Studio 2008 (all of the CVS plug-ins I have tried have had either serious functionality issues, or serious stability issues).
VSS is really a terrible source control system, and moving to a modern style (optimistic locking) source control system will be a huge boon in the long run. You might want to skip the 1990s all together though and move to Subversion/Git/Mercurial and get into the 2000s.
If you must switch to CVS (Subversion or a distributed VCS would be better) then the script we used to migrate and keep the change history can be found here.
We are very happy with CVS, although we don't use Visual Studio integration as we find TortoiseCVS and SmartCVS much better. However if I was switching now I would look at Git or Mercurial.
My hack is as follows:
I am mainly a Java developer and I use Eclipse/RAD. The support for CVS is great and is very easy to work with.
For the C# work I do I tried to find a CVS plugin for Visual Studio but was unhappy with the one I found. In the end, I decided to use Eclipse to handle the versioning of my C# projects.
The procedure:
Create a simple project in Eclipse
Open VS and save the project into the directory created by Eclipse
Return to Eclipse, press F5 to refresh the project
Share the project (i.e. add to CVS)
Add .sln to the list of externally handled files in the Eclipse settings
VS can now be opened directly from Eclipse by clicking the .sln file, the project can be worked on within VS. Upon exit from VS the project must be refreshed in Eclipse and can be synchronised with CVS
Although I have not yet used the Subversion plugin, I guess that would work in a similar way.
This solution works well for me especially as I spend most my time in Eclipse anyway.
I did try using TortoiseCVS but found it tricky to use. Eclipse is free and the CVS interface is very usable.
Visual Studio has a bad integration inside the IDE for CVS and SVN. Those free ones don't work well. I use Tortoise (outside Visual Studio), and it works fine. If you want something inside Visual Studio, you might check for not free plugin or to use TFS.