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?
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.
My dev environment is Visual Studio 2010, with Resharper 5.1.3000.12 and AnkhSVN 2.1.10129.17 installed.
It's my understanding that Resharper should notify AnkhSVN (or VisualSVN, etc) when a Refactor->Move command is done on a file, to maintain the SVN history on the file. However, when I do such a refactor through the Solution Explorer in Visual Studio, AnkhSVN treats the file move as a delete/add, thus losing the SVN history for that file. In fact, Ankh doesn't even add the new version of the file, it just deletes the old one, and I have to manually "add" the new one before I can commit.
HOWEVER, if I do a Ctl-X,Ctl-V through the Solution Explorer to move the file, Ankh detects it as a copy/move and maintains the history, auto-adds the new file, and generally behaves as one would expect.
Does this work for anyone else, and if so, did you have to do anything tricky to get it to work? Have I missed a setting somewhere to wire up AnkhSVN with Resharper, do I perhaps need new versions of either plugin, or perhaps this is some kind of installation order problem? (I installed Resharper first, then Ankh).
A certain amount of work has been done during ReSharper 6 release cycle to make sure that ReSharper's Move refactorings resulted in VCS moving them instead of deleting and adding new files.
However, as there has been no comprehensive QA for this piece of functionality, it has not been announced as a part of ReSharper 6 set of improvements.
In other words, there's no guarantee that ReSharper 6 will behave better in your scenario but it's worth a try upgrading.
Accordingly to the Jetbrains task tracker, it's still not fixed. You may track it here: http://youtrack.jetbrains.com/issue/RSRP-179384.
Issue is related to TFS but it's also reproducible with AnkhSvn in VS Professional 2012.
ReSharper version: 7.1.1 C# Edition (Build 7.1.1000.900)
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.
We are in the midst of transitioning from asp, vbscript, SQL Server 2000, to asp.net mvc, sql server 2008.
When we were using classic asp, we could use Dreamweaver to lock access to a file on the network so that developers and designers wouldn't overwrite each other's changes when saving.
Is there an equivalent feature in Visual Studio 2010? Or, are there other techniques to accomplish this?
There most definitely are techniques to accomplish this.
Based on the upgrade, it sounds like the team is moving forward. Maybe that means business is good, maybe that means the team is growing or will grow, etc. In any event, and even if it's just a single developer, file locking to prevent overwriting each other's changes is no solution at all. Proper source control should always be used.
Visual Studio has support for TFS, naturally, but there are plugins for other (free) systems. SVN is a good one to get started. (Though, personally, I don't like IDE integration of source control. I prefer to see it as a file operation and not a code operation, and therefore prefer the Tortoise revision control clients for their Windows Explorer integration.)
You will almost certainly want to transition to a proper version control system.
Subversion is very popular and works well for most. TortoiseSVN is an extremely useful Explorer extension to make Subversion easy to use. There are also plugins for development environments. VisualSVN (not free) and AnkhSVN both integrate Subversion into Visual Studio.
Git & Mercurial are also very popular. Both are designed with distributed teams more in mind. They work largely the same as Subversion, but each version control system has slightly different "best practices" when it comes to work flow, particularly around branching and merging.
#quakkels: Go for TFS. I deeply hate it, but it will be easier for you.
SVN is for geeks, and GIT is for alpha-geeks (or for wanabes like me).
Putting aside the fact that one is open-source, which tool is more feature rich and performant for SVN support within Visual Studio.
I've recently switched back to Ankhsvn (2.0) from VisualSVN. Prior to VisualSVN I was using Ankhsvn (1.0).
I prefer AnkhSVN 2.0 because it integrates with Visual Studio as a source control module, rather than an add-in and as a result it feels more like using Visual SourceSafe (which I am forced to use at my 9 to 5). Basically it integrates with Visual Studio the way Microsoft intended source control to integrate with Visual Studio.
For me it simplifies going back and forth between Visual SourceSafe and Subversion since they both behave essentially the same way.
I like AnkhSVN mostly because it is free. BUT, I love the VisualSVN server.
I didn't like either one. Using the shell/tortoise was preferable for me.
I paid for VisualSVN, its just worth it, even though I usually side with free (and even inferior) software. And by separating concerns by handing the actual SVN stuff to TortoisSVN, you get the best of both worlds.
Ultimately its down to how you work, and what you're used to, and since I was already using to TortoiseSVN, VisualSVN was a no-brainer.
I like the way that VisualSVN keeps you closer to tortoise. I also like its diff tools better.
I'm not sure if they changed it, but Ankh did not allow renaming of files in VS when I last used it. That was a pretty big pain for me as I have refactoritis and generally suck at naming files really well the first time.
VisualSVN for me. I've found it to be much more stable than Ankh.
+1 to VisualSVN because: a) it delegates most of the work to TortoseSVN, and b) it handles all move/rename shenanigans I throw at it from the Solution Explorer.