>> 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.
|