Which SVN client do you like best?
-
needs to integrate with visual studio
<rant> Tortoise is horribly counterintuitive. It seems like for anything beyond commit and update there's no obvious way to do it. I frequently find that NONE of the presented options seem like they'll do the operation I want to. </rant>
-
yeah Microsoft's VSTS, why? :~
You might just be the first one I've heard that actually likes it. I have worked with it (as a programmer) and found it to be somewhat crude compared to Subversion. Maybe there's something in it for testers and Q&As that makes it better than Subversion. If you compare bang for the buck, Subversion is hands down the winner. I'm currently holding about a million lines of code, in several branches, and I find it to be more than apt to handle the job.
-
You might just be the first one I've heard that actually likes it. I have worked with it (as a programmer) and found it to be somewhat crude compared to Subversion. Maybe there's something in it for testers and Q&As that makes it better than Subversion. If you compare bang for the buck, Subversion is hands down the winner. I'm currently holding about a million lines of code, in several branches, and I find it to be more than apt to handle the job.
I think the ability to associate source control with taks, scenarios of a methodology that at the same time is integrated with every part of your project is a killer system overall, branching, history, versioning of any file and all its features is the way to go for short and large teams that uses the VSTS as whole and that in v2010 becomes even better, about the bang for the buck well its free you know for startups, and low cost for msdn subscribers and partners, I dont really think someone goes for the VSTS by their own buying it in Amazon :)
-
needs to integrate with visual studio
A bit surprised how few people use Ankh. Version 2+ is great - it is the only SVN VS source control provider that I know of - the others are all plugins AFAIK. Why is this bad, well if you want integration, then why not do it properly - it also makes it much easier to convert people from VSS ;-) Tortoise is a great backup - for infrequent operations like renaming the folder that a project is in.
-
...Is any client that stays well away from Visual Studio. (I have yet to see a source control system integrated with VS that actually does what i want: stay completely out of my way 'till i'm done working. For SVN, i use Tortoise... )
There's a free way to integrate Tortoise with Visual Studio that I use and enjoy: http://blog.programmerslog.com/?p=4[^]
-
I had the same sentiments before I tried Visual SVN (plugin for VS). It really does stay out of your way, as well as give you a good overview of what has changed, etc. For a measly $49, it's well worth its price.
-- Kein Mitleid Für Die Mehrheit
AnkhSVN all the way. Ankh is (now) a full SCC implementation. I have tried Visual SVN but found it has the same problems that Ankh V1 had. The problem is that VisualSVN needs to know intamate details about different project types, and it has to be coded to explicitly support them. This meant that when you use a unsupported project type you basically need to email them and wait for another release untill you can use VSVN on it. While if you use AnkhSVN 'it just works' and its GUI is well suited to Visual Studio - while VSVN simply puts up a modal box and shells to TSVN which does the real work. http://ankhsvn.open.collab.net/[^]
-
...Is any client that stays well away from Visual Studio. (I have yet to see a source control system integrated with VS that actually does what i want: stay completely out of my way 'till i'm done working. For SVN, i use Tortoise... )
I used to use TortoiseSVN 'cos there was no free VS integration for SVN (VisualSVN[^] is $49 a piece). Then came a stable and full featured version of ankhSVN[^] - version 2.1. Now I use ankhSVN most of the time and only go for TortoiseSVN for stuff that doesn´t show up in VS. Believe me, ankhSVN doesn't get in the way until you tell it to do something.
-
AnkhSVN all the way. Ankh is (now) a full SCC implementation. I have tried Visual SVN but found it has the same problems that Ankh V1 had. The problem is that VisualSVN needs to know intamate details about different project types, and it has to be coded to explicitly support them. This meant that when you use a unsupported project type you basically need to email them and wait for another release untill you can use VSVN on it. While if you use AnkhSVN 'it just works' and its GUI is well suited to Visual Studio - while VSVN simply puts up a modal box and shells to TSVN which does the real work. http://ankhsvn.open.collab.net/[^]
I did try an Ankh-version, but I found it to be less than reliable. I can't remember what version it was though. :~ As for Visual SVN, yeah, it's a bit "hard wired" to the IDE, but it doesn't matter much for me. It knows C++ and C# project types, and that's what matters for me. I suppose I could give Ankh a try again, but right now it's too much hassle. I'm in the middle of a pretty stressful development cycle. :sigh:
-- Kein Mitleid Für Die Mehrheit
-
needs to integrate with visual studio
I've used TortoiseSVN and AnkhSVN a bit. However, TortoiseSVN on its own is good enough really. Just tried ankh out of curiosity.
Kevin
-
A bit surprised how few people use Ankh. Version 2+ is great - it is the only SVN VS source control provider that I know of - the others are all plugins AFAIK. Why is this bad, well if you want integration, then why not do it properly - it also makes it much easier to convert people from VSS ;-) Tortoise is a great backup - for infrequent operations like renaming the folder that a project is in.
The Real Geek wrote:
it also makes it much easier to convert people from VSS
True, although most of the time using VSS I ran it outside VS. Mainly this is because of some nasty experiences with integration in the past. There was a nasty VS 6 (C++) bug that could cause a source file to disappear completely, i.e., even from the recycle bin (eventually fixed in one of the SPs). Ever since then I've been neervous of VS integration. Although I did in fact try Ankh and indeed have it installed at home (although not using it).
Kevin
-
Why would you not want Visual Studio integration? Who wants to have extra windows open and not have everything in one IDE? We use Sourcegear running from our webserver and everytime we check files in, it writes to shadow folders which essentially becomes our staging environment. Clients can see projects being developed in real time and our staging server is always up to date. This set up works for us with no issues. What are the issues that people have experienced that have put them off VS integration? Sasha http://www.webcoda.com.au
sashashev wrote:
What are the issues that people have experienced that have put them off VS integration?
In VC++ 6 days there was a nasty bug in VSS integration that could cause you to lose a source file. Took me years to get over it, i.e., would always run VSS independently. But I'm more relaxed now. I have used AnkhSVN without issues in fact (and also VSS).
Kevin
-
You can exclusively checkout in SVN, although you are right in that you don't get to see in real time whether a file is locked or not, unless you specifically query the repository. But that is rather easy using TortoiseSVN, and on top of that a lot faster than VSS as well. You probably won't see a lot of problems with only 5 or 6 users, and if all are working at the same local network, maybe not even 12. But that very much depends on the project and how likely it is that two people would need to work on the same files at the same time. That said, non-exclusive checkout is much less of a problem than some people think. In truth, SVN doesn't really do that: the files that you have on our own hard drive are not considered checked out files, but rather a copy of the repository's state at a given time. You only 'checkout' the moment immediately before you try to commit your changes to the repository. At that point, your SVN client will make sure that nobody else changed something in the meantiem, and if someone did, will reject the commit and ask you to adapt your changes to the new state of these files. Luckily it can do this on it's own, using 'merge' - and here is probably the cause of your and many other people's horror: The computer will automatically do the job of merging other people's changes with yours, without you supervising it. Can you believe that the computer can do this job more reliably than you? Obviously the answer is 'no' for you. I admit that I used to be rather sceptical of this specific aspect of non-exclusive version management system myself, but over the years I have learned that it is, in fact, the better way! Not only does it safe a lot of work for the user, it is also at least as reliable in doing this as most people doing it by hand! Moreover, it _will_ reliably point out possible conflicts and leave those for the user to resolve. I have used VSS in various projects with 3 to 20+ people over more than 10 years, and I've used SVN in projects of 3-20+ people in the last 5-6 years. I must say I don't miss the waiting for the repository to respond, I don't miss the downtimes due to a much needed cleanup, I don't miss having to wait for other users to checkin their stuff even though they actually never changed the file I want to edit. And I don't miss having to refix an old bug that I did fix before, but got lost in the void eventually. And yes, this happened on quite a few occasions. We could even make our repository or parts of it(!) accessible over the web if ever we wanted
Stefan63 wrote:
That said, non-exclusive checkout is much less of a problem than some people think.
I worked with SVN for the first time in 2007-8. It was new to a number of contract developers there. We were all sceptical of non-exclusive checkout, it being the first time we'd encountered it. However, in practice it didn't seem to cause any more problems than exclusive checkout! It's one of those things that intuitively seems horrendous but isn't.
Kevin
-
If you absolutely need integration into VS, AnkhSvn works quite well. Make sure you get the most recent version, which is compatible with both VS 2005 and 2008. Might work with 2010 as well, haven't tried it. It's unobtrusive, for the most part. It's biggest benefit is that it allows one to rename files from within the IDE, something that is, depending on one's irritation threshold, a minor or major pain in the posterior using either the CLI, Tortoise, or other non-integrated client. It still doesn't do so well with moving files between projects, and apparently doesn't fully support all Visual Studio project types yet, but so far, it's failings have not hindered me, and it's actually made my life a bit easier. I still use TSVN for diffs and merges and such, and the CLI for scripting, but AnkhSvn is well worth a look. And it's free. Brad
One problem I ran into with using both is that I started with Tortoise and then many months later tried Ankh and the two client versions weren't synchronised. Tortoise was 1.5 and Ankh was 1.6 or something. So I then had to update my Tortoise to 1.6. After that it was fine, though only used Ankh for about a month before my contract ended.
Kevin
-
One problem I ran into with using both is that I started with Tortoise and then many months later tried Ankh and the two client versions weren't synchronised. Tortoise was 1.5 and Ankh was 1.6 or something. So I then had to update my Tortoise to 1.6. After that it was fine, though only used Ankh for about a month before my contract ended.
Kevin
That's true with any Subversion clients, however. For some releases, the developers advertise on release that touching a working copy with a client built with the new libraries will upgrade that working copy. It doesn't matter if that client is Tortoise, Ankh, the CLI, Subclipse or any other client. If you're working fine with one client, then there's no reason to change. I find Tortoise to be insufficient for use with Visual Studio, since I spend a fair bit of time inside the IDE, and some operations, if done with Tortoise, would require me to get out of VS, edit solution and project files, and other hoop jumping to accomplish. YMMV.
-
That's true with any Subversion clients, however. For some releases, the developers advertise on release that touching a working copy with a client built with the new libraries will upgrade that working copy. It doesn't matter if that client is Tortoise, Ankh, the CLI, Subclipse or any other client. If you're working fine with one client, then there's no reason to change. I find Tortoise to be insufficient for use with Visual Studio, since I spend a fair bit of time inside the IDE, and some operations, if done with Tortoise, would require me to get out of VS, edit solution and project files, and other hoop jumping to accomplish. YMMV.
Brad Stiles wrote:
since I spend a fair bit of time inside the IDE, and some operations, if done with Tortoise, would require me to get out of VS, edit solution and project files, and other hoop jumping to accomplish.
Of course, if you're Nemanja Trifunovic then you would do everything from the command line. ;P
Kevin
-
Unfortunately I don't get to choose what (version) I'm working with. Not going to upgrade before end of year, more likely next year, maybe not even then... If VS 2008 works that well with VisualSVN (or AnkhSVN) I wouldn't know. Unfortunately I didn't find a trial version of VisualSVN (or any other useful tool in that area) that still works for VS 2003, so I'm not going to find out myself anytime soon :( I am wondering about the icon cache you mentioned. I am working on Windows XP, still, but found that it's sometimes slow to update TortoiseSVN Icons when using several instances of explorer. Can you give me a hint where to look for that setting? Maybe I can find it on XP as well.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer] Add (or set) the string value "Max Cached Icons" to "4096".
-
needs to integrate with visual studio
Free: http://ankhsvn.open.collab.net/[^] Commercial: http://www.visualsvn.com/[^] For a 2-minutes-win-svn-server, you can use free Visual SVN Server http://www.visualsvn.com/server/[^] Nando
Jesus
-
...Is any client that stays well away from Visual Studio. (I have yet to see a source control system integrated with VS that actually does what i want: stay completely out of my way 'till i'm done working. For SVN, i use Tortoise... )