Which SVN client do you like best?
-
What's so funny in his post? Would you mind sharing the humor with others?
It is a crappy thing, but it's life -^ Carlo Pallini
-
needs to integrate with visual studio
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
-
needs to integrate with visual studio
Tortoise SVN for Windows Explorer AnkhSVN for Visual Studio
with best regards vb4arab.com
-
What's so funny in his post? Would you mind sharing the humor with others?
It is a crappy thing, but it's life -^ Carlo Pallini
I have no idea ... but this thread reminds me why I really should just stay out of the forums. I checked this thread out because of an interesting-looking link in my daily newsletter, only to find just 3 or 4 useful posts and the rest are nothing but immature ridiculous drivel. Disgusting.
-
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.
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; -
needs to integrate with visual studio
SourceSafe, because it's the client I use. Muwahhhaaahhhaaa!
Software Zen:
delete this; -
...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... )
-
The 'limitations' you're talking of are really the 'limitations' of SVN, not of TortoiseSVN (or any other tool for that matter). And it is no limitation at all once you understand there are three levels of abstraction you are working with: your file system, the subversion client (which is what TortoiseSVN encapsulates), and the subversion server. I don't know about newer versions, but it's impossible to move files from inside Visual Studio 2003. That means you'll never even run into the kind of problems you describe, unless you're doing things outside VS already! And short of editing the VS project files manually(!) it is rather tedious to clean up the mess created by such moving around. Better not bother, or best just set up the whole project/solution anew! That said, I've tried earlier versions of Ankh SVN (the newer ones sadly only work with newer versions of VS), and apart from seeing the state of each file inside the Solution Explorer I found I got little use out of it. One of the more annoying things is that it tends to switch the common output window to display Ankh messages instead of build or debug messages. And it does that way too often for my taste! The only reason I still have it is that in my experience removing a tool from the VS interface tends to leave some ugly remnants in the VS UI, even if in the file system there is not a single other trace left of the tool in question! One thing I definitely didn't like about AnkhSVN - and I am sure that still is true for newer versions of both VS and AnkhSVN, as well as VisualSVN - is when you do soemthing from inside VS, TortoiseSVN does't update file and directory status by itself, and vice versa. You can easily get confused if you use both, and since TortoiseSVN offers much more functionality, I'd advise to only use this. Also, you'll often have files related to a project that are not accessible from VS, simply because they are not code or resouce files: for example files created by an UML tool that itself is used to generate the initial code, or even gets synchronised with your code base. You cannot properly handle these files from within VS, so you need TortoiseSVN for that task. TortoiseSVN is _the_ client for SVN. Maybe if you have a newer versio of VS, AnkhSVN or VisualSVN might provide some of TortoiseSVN's utility from inside
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.
-
I have no idea ... but this thread reminds me why I really should just stay out of the forums. I checked this thread out because of an interesting-looking link in my daily newsletter, only to find just 3 or 4 useful posts and the rest are nothing but immature ridiculous drivel. Disgusting.
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
-
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.
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
-
needs to integrate with visual studio
-
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.