Which SVN client do you like best?
-
You're like a regular Einstein up in here: brain dead for several decades. It's called a thread. It's where several people can see the course of a conversation. Just because a reply was to your comment doesn't mean he can't read it, or that it wasn't meant for both of you. You idiots get your panties bunched up way too easily.
Codemonkeys don't do it at all. Too busy coding.
Naruki, people were trying to have a nice little discussion about a topic of general interest and you have very skillfully converted it into a debate about who is the biggest jerk. Well done. Ok, you have my vote on that one - now can you please drop this silliness so we can get back to something useful? :zzz:
-
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;Gary Wheeler wrote:
I have never lost history information or code due to a SourceSafe fault.
That's probably because you smartly run a nightly Analyze. Good call! That's what I used to do as well, years ago.
-
I tried my levels best to see if at all you will be able to give any meaningful argument. But you've been just consistently abusive (in every message of yours), childish and silly. But, I'm not surprised to look at what comes out of you because giving a sensible argument means having any amount of intellectual firepower. Probably it may have something to do with the way you were brought up, lack of education, loneliness, or whatever. I'll ignore you, which I should have done way back. :)
It is a crappy thing, but it's life -^ Carlo Pallini
You're a lying hypocrite. You insulted the hell out of me (and again in this latest comment) all while pretending that insulting people is evil. I can only guess you are a "true believer" type of moron who has convinced himself he isn't doing anything wrong. Good luck with that, dipwad. Bet you a million dollars you lie about ignoring me, too.
Codemonkeys don't do it at all. Too busy coding.
-
I do understand. I was just trying to find if he'll give me an interesting or rather meaningful argument (as he has a different opinion), but he was only abusing consistently instead of justifying his opinion. I must have ignored him instead of giving him a space. I'll do it now. :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
Naruki, people were trying to have a nice little discussion about a topic of general interest and you have very skillfully converted it into a debate about who is the biggest jerk. Well done. Ok, you have my vote on that one - now can you please drop this silliness so we can get back to something useful? :zzz:
Takes two (or more) to argue, and I have only been skillful at pointing out what the idiots have been doing. If they shut up, then I will have nothing more to add. Talk to them. But watch out for their revenge mods and insults while condemning insults. Nasty stuff, those hypocrites.
Codemonkeys don't do it at all. Too busy coding.
-
needs to integrate with visual studio
-
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/[^]