True, but I don't use the command line whilst developing in Eclipse. I point to the project and click on 'update'. Or 'Create patch'. Or 'Apply patch'. cvs -Rt? diff -u-r? No idea. Don't care, either :-)
I suspect you're not winning hearts and minds with this attitude, irregardless of smileys :) I'm sure a number of people here don't care about what you can click on in Eclipse. IDE support wouldn't be my first criterion for choosing source control, but telling me you don't care isn't making me sympathetic.
True, could have used better wording.
But at present, SVN isn't supported in my primary development tool. You're asking me to come out of the tool that I use to work and run a few command line options to get/update/commit changes. Instead, I can do these things within Eclipse at the moment with point-and-click for CVS.
Me, me, me. Here, you're a member of a community first and foremost. What do you think is the best choice for that community?
I don't know what the best choice is. It may well be that what's best for the community isn't what I find the easiest solution, or what I'm used to. However, I'm sure that I'd adapt should a move occur.
It's true that SVN has a number of advantages over CVS from manipulating the repository, of which I'm not doubting, but IMNSO the advantages aren't huge. As long as it can be used to check software in and out, then that provides pretty much what I'd expect from a source code control system.
And from what I see, the major disadvantage of CVS is that you loose changes during moves.
This is a major disadvantage, particulary with Java and the idiom that package structures must be reflected in directory strcuture (not required, but that's how the tools are).
True, this is where CVS has fallen down. And if there were a decent fix for CVS, that'd be great. But there isn't, and SVN provides such benefits.
I'm also pretty sure that even with SVN tools available, should it replace CVS as the de-facto standard for source code then my favourite IDE will have them eventually as well :-)
I think it boils down to which is done more often; moving files from one directory to another (and then wanting to access changes prior to the move after it has happened), or checking code in and out using my IDE interface. I'm going to do the latter daily; the former I don't think I'd want to do maybe two or three times in the project's lifecycle. Optimising the latter in detriment to the former isn't a worthwhile tradeoff for me.
Like I said. Me. me, me.
Yes, I was expressing a personal opinion there. My personal opinion may not be the same as other people's, but when working in a group I know that it's not so much a matter of what everyone's individual opinions are, but a consensus opinion of the group. I also think it's a good idea to discuss differing opinions to find out where there are overlaps, and to re-evaluate one's own opinions. And lastly, I'm wrong more often than I'd care to admit and sometimes need a little convincing :-)
I wanted to raise the issues associated with moving from CVS to SVN in my experience; but not to say 'You cannot do this because ...' Clearly as a group a number of us want to move to SVN, and I was highlighting some of the potential issues to solve in that transition as/when it occurs. In particular, I wanted to express the potential problems that may occur when using an older version of the subversion client; although I've not used it, I was concerned to read about inter-operability with older/newer versions of the SVN software.
I also appreciate the other feedback people have given, and am currently downloading the svn-client on my system to play around with.
Alex.
