Which SVN client do you like best?
-
needs to integrate with visual studio
I'm not a fan of SVN. It has repeatedly decided to remove entire subfolders after clicking commit, clean, or update. Then going in and trying to do a checkout, removes them from SVN.:mad: Talk about a crappy day. Pulling from backups is lame. Before doing any commits now, I copy the entire project to another folder named with the project name and date. But, some people have good experiences with it. (Where's my good experience, can I have one?) But, we use Tortoise and Visual SVN. Visual SVN works pretty well for me. It hasn't deleted anything, its when using the Tortoise client that things go to hell in a handbasket. Whenever I create a file or folder then delete it before commiting the creation, well, thats just a disaster, copy project, remove .svn folders, do a fresh checkout to a new folder, then find the files that changed, and copy them back to the new checked out, then commit. The only workaround that I have found. Commit after each change. Lame.:mad: I am trying to convince everyone here to use something different. Something that doesn't blow away months of work in half a second....:mad:
Those who are too smart to engage in politics are punished by being governed by those who are dumber. - Aristotle
-
I have three SourceSafe data bases, ranging from 300M to 4G in size, each with 8-12 users. I run the Analyze tool nightly to check the data bases. The same scheduled task backs up the data bases as well. I have never lost history information or code due to a SourceSafe fault.
Stefan63 wrote:
Every commited change will create a new file on your filesystem - the horror!
And how is that different from a SQL data-base-backed source control system that writes megabytes of data base crap hither and yon for a 3K source file commit?
Software Zen:
delete this;>> I have never lost history information or code due to a SourceSafe fault. As I said, my experience ranges back to more than 15 years ago, last time I worked with VSS and got these kind of problems was at least 7 years ago. After losing quite an amount of work and time due to repository inconsistencies we learned the hard way that scheduling AnalayzeAndFix once a week is not enough! It is possible VSS improved over the past years, maybe it does finally work more reliably, but I can't tell. I still maintain that a tool that requires a regularly scheduled 'Analize and Fix' to run reliably sounds like it's been broken from the start. >> And how is that different from a SQL data-base-backed source control system that writes megabytes of data base crap hither and yon for a 3K source file commit? I am not sure what kind of databases you are basing this assumption on. Every database system should be able to easily outperform any windows file system there is. SVN goes out of it's way to make sure only the minimal amount of data gets transferred over the network. If you never tried out SVN you should at least check out it's documentation, or the documentation from TortoiseSVN which, btw. is very good.
-
VS2003? Really? People still use that? :laugh: Jokes aside...I'm talking about VS2008 with the newest version of VisualSVN. Everything you speak of is a VS2003/old VisualSVN issue. Apparently VisualSVN has some tricks in it's arsenal now that TortoiseSVN doesn't have, because everything JUST WORKS within Visual Studio, including dragging crap around and renaming/editing to your hearts content without breaking SVN ;) That is the beauty of it. And the status icons for TortoiseSVN stay in perfect sync with VisualSVN (I had to increase the icon cache size on Vista for this to work properly, which also happened to fix a lot of other explorer-related issues). What's also nice is automatic exclusion of things like bin folders and user setting files. You can do whatever you want from within Visual Studio and it just does the right thing...I can't stress how easy it is, assuming you stay within Visual Studio. If you need to do something in the file system, you always have TortoiseSVN for those "other" things, which is usually fairly easy to manage because it is individual files (a document, a mockup picture, etc). If you generate code outside of Visual Studio then just generate it normally, go into Visual Studio, add it into your solution, and bam, VisualSVN adds everything to source control.
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.
-
I'm not a fan of SVN. It has repeatedly decided to remove entire subfolders after clicking commit, clean, or update. Then going in and trying to do a checkout, removes them from SVN.:mad: Talk about a crappy day. Pulling from backups is lame. Before doing any commits now, I copy the entire project to another folder named with the project name and date. But, some people have good experiences with it. (Where's my good experience, can I have one?) But, we use Tortoise and Visual SVN. Visual SVN works pretty well for me. It hasn't deleted anything, its when using the Tortoise client that things go to hell in a handbasket. Whenever I create a file or folder then delete it before commiting the creation, well, thats just a disaster, copy project, remove .svn folders, do a fresh checkout to a new folder, then find the files that changed, and copy them back to the new checked out, then commit. The only workaround that I have found. Commit after each change. Lame.:mad: I am trying to convince everyone here to use something different. Something that doesn't blow away months of work in half a second....:mad:
Those who are too smart to engage in politics are punished by being governed by those who are dumber. - Aristotle
I can easily understand your worries. When you've never worked with such a system before, I'ts hard to understand SVN's workings, and why, in truth, none of the bad things you mentioned never really happened - at least from the point of view of your SVN client ;) However, other version control systems will confront you with the very same, or worse, issues. Rest assured that SVN is one of the VCS where it's actually very hard to permanently destroy data. At least data that's already in the repository. If you lose something, there's a good chance someone who's well versed with SVN will be able to bring it back. My best advice is: voice your problems! Tell your boss or whoever is in charge of SVN that if you're supposed to work with SVN efficiently, you absolutely need to understand how it works and what you're supposed to do, and not do! Unlike many other programs, it really helps to understand the inner workings of SVN to be able to work with it efficiently! If noone is going to take the time explaining it to you, try the TortoiseSVN documentation. It is really very well structered and easy to grasp. I suggest you take a closer look at chapter 2 (Basic concepts) and make sure you understand it before delving into chapter 5 (Daily Use Guide).
-
You mean Microsoft's VSTS? You're kidding right? :~
-- Kein Mitleid Für Die Mehrheit
yeah Microsoft's VSTS, why? :~
-
In a single user environment, VSS tends to run resonably well, and if your repository is on your own hard drive, it's even reasonably fast - although it will tend to fragment your drive no end! Every commited change will create a new file on your filesystem - the horror! In a multi user environment - even if it's only two people - VSS tends to be slow, unreliable, and prone to data loss or repository conflicts. You may not be able to notice it within a week or two, but IME, running it for 10 users over the course of more than a few weeks requires you to run the builtin repository cleanup at least once a week, or it will simply stop working. And every cleanup is likely to destroy some of the history of your development as well! Not to mention that it's entirely possible some of the data that got destroyed is actually part of your current code base. And more often than not, since older versions of your code normally compile just as well, you'll not even find out about that until much later, when your clients start complaining about a bug you fixed years ago! VSS is a sure way of destroying your work. TYVM, I don't need a tool for that.
For multiuser environments there is not better than Source Control in VS Team System :wtf:
-
needs to integrate with visual studio
If needs to integrate to visual studio, I prefer Ankh because it works and it's free. But I still prefer using TortoiseSVN only.
-
needs to integrate with visual studio
-
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