We're thinking of switching to SVN at my work, so I was wondering about SVN plugins for VS2008 (and 2010 when it comes out). After a bit of research I found AnkhSVN and VisualSVN, the 2 that seemed most dominant. (I am aware of TortoiseSVN and will use the plugin in conjunction with it).
I am aware that this has been asked before, but these questions were asked almost a year ago and we all know that a lot of things can change in a year.
The question: From your experience, which is better and why?
Granted, it has been a year since I've used each product head-to-head, but my current preference is AnkhSVN. Though folks grumbled about early versions of AnkhSVN, 2.0 was a near rewrite of the original and is now a full Source Control Provider Integration Package rather than a Visual Studio Add-In. With commercial backing from CollabNet and renewed open source enthusiasm, AnkhSVN 2.0 deserves a chance.
My two favorite features of AnkhSVN are it is free and I love the Pending Changes window.
As for VisualSVN, I find it to be sluggish and I feel it leverages TortoiseSVN rather than handling the file management itself far too often. And it costs money (albeit a small amount.)
Again, this is based on my last head-to-head test which was about 1 year ago. As already stated, TortoiseSVN is great on it's own, but if you really want to plug into the VS IDE, give AnkhSVN a whirl before VisualSVN. Best of luck.
I have tried both of the VS plugins...after several months of use I quickly realized that I spent ALL of my time in Tortoise! The plugins don't get all of my trunk related items. They only work with items that are part of the solution and that VS recognizes. For this reason I spent pretty much all of my time in Tortoise...and eventually all of my time. There is no reason to pay for plugins when Toroise is both free and updated almost daily.
Stick with Tortoise and learn how to use it. You will be happier in the end.
Responses:
@jeroenh: "... There really is an advantage of using a (properly integrated) VS plugin, namely when moving/renaming files in your solution. ..."
I agree that renaming/moving files in Tortoise is clumsy. And VisualSVN does make this easier.
@Darko Z: "on a personal level I agree, but on an organisational level I don't. We have a few people here that NEED VS integration. Yeah its silly but fair enough :)"
Yes, I have several people like that in my current team. And training them to get used to Tortoise has been a Bear! They are the reason that we got some licenses for VisualSVN..but they complained about that too.
I had the same dilemma as well a few months ago, and finally decided to go with VisualSVN. We've been using it for 4 months for C# inhouse web application development and our experience has been positive.
Firstly, the server part integrates with Active Directory and offers an easy to use MMC control for managing the repositories.
Secondly, the client part integrates with VS2008, doesn't slow down Visual Studio loading times, and works with pretty trivial color codes (green for untouched files, yellow for files you changed). It features full revision diff's, you can comment every revision.
One down side is that its supports for hooks (like post-commit hooks) is very rudimentary.
You can view statistics like who made the most commits, etc. It supports branches although we don't use those features. All client-server communication is done through SSL (keys and certificates are configured automatically).
I asked them a question at some point about how to delete the branch history from the Visual Studio dropdown, and their support answered that I simply needed to delete the .suo file (efficient customer service)
Finally, my experience from working with VisualSVN: simple and straightforward for our relatively small team. (we're 5 programmers, but I'm pretty sure this scales a lot more than that).
I use VisualSVN at the moment, and it's great as it auto-adds any new files to the SVN and allows easy revert and diff without having to open an explorer window. However, you will still need to use TortoiseSVN for files not in your Visual Studio solution.
Last time I used AnkhSVN it didn't work too well and screwed my SVN checkout up (but this was a couple years ago).
I have used both and prefer Visual SVN (as of v3.0.4) because of its integration with Tortoise SVN which I already use and am quite familiar with. Because of this familiarity and VisualSVN's integration with it I prefer it a bit more.
I believe there is argument that AnkhSVN (as of v2.4.11610) has more features integrated into VS.NET, but it is working with it's own dialog windows and prompts which are not hard to get used to, but again I liked the functionality and familiarity of Tortoise SVN.
Also since all of my shop uses Tortoise SVN via Windows Explorer, the transition to Visual SVN ins't such a big deal other than adding the nice integration directly into VS.NET. I suffered none of the pitfalls commented in the other posts here (most are from 3-4 years ago it seems) when I used VisualSVN over the last 30 days.
So here is what I say: if you are a heavy user of Tortoise SVN and like how it works, go with VisualSVN. If you are new to Subversion and really don't care, then going with the free AnkhSVN with its additional integrated features is probably the way to go.
That question you asked boils down to personal preference but I would advise you to have IN ADDITION to the ide client either Tortoise SVN or the command line client. You will often be forced into positions where the IDE client cannot perform the task you need.
来源：https://stackoverflow.com/questions/1252672/ankhsvn-vs-visualsvn