(I'm sorry that I'm breaking threading, but I don't feel to bad about this given whom I'm replying to, it's not like I'm cutting a huge thread in two)
Richard Kenner wrote: > I must say that I find the amount of "fiddling" and special options or > configurations needed here very disturbing. People make a comment and one > of the experts gives an answer of the form "oh, just turn on <yet another > obscure option in some tool>". > > This is barely described in a wiki, let alone in any real documentation. And > lots of people don't even like to read documentation. Plus, a huge amount of > hackery will scare people off. All these options are meant to address specific concerns people are having, they are not required to use svn effectively. ssh multiplexing in particular applies equally well to cvs as well. > I'm very concerned that we're greating increasing the barrier to entry for > work on GCC. cvs is very intuitive and simple to use. I'm not seeing the > same thing for svn/svk, but instead a series of increasingly complex > suggestions on how to do things efficiently. If you don't want to do things more effectively than in cvs (svn merge comes to mind) there really is no great difference in using svn. Tags, branches and revisions are in my opinion _much_ easier to understand in svn. How many people really understand how cvs version numbers come about, when stuff ends up in the attic etc (I remember this question appearing on fortran@ just last week); how again do you figure out the set of files changed in a single cvs commit (you don't, you search through the gcc-cvs archives) etc. svn _is_ easier, and it's not difficult to install, as the downloadable source tarball is self-contained (or "reasonably self-contained", it required no additional downloads for building on the rather barebones setup my institute is using) > Saying "casual developers of GCC can use snapshots" is not something I think > we ought to be doing. I don't think so either. Since a lot of people have expressed concerns WRT to the switch, I'd like to say that I'm all in favor of switching, and I think that I'm speaking for a not-so-vocal majority. I've had to wait for a lock too often, and working on branches (esp backporting patches) has cost too much of time for me to be a fan of staying with cvs. The increased disk usage will be compensated for by the easy means of switching a checked-out tree between branches. The only issue I'm having is that there seems to be no way of excluding certain directories in a checkout, e.g. I have zero interest in Ada, yet it takes up a lot of diskspace (and no, 'svn co -N' is no alternative). Finally, the move to subversion was agreed to in February, the increased disk usage was discussed then, and a test repository was setup back then. I found a few issues (svn ann ChangeLog comes to mind) which I made sure Daniel Berlin knew about, and the next released version of subversion contained fixes for them. It completely escapes me why so many people didn't deem it necessary to give it a spin back then, especially given the fact that Daniel Berlin committed to fixing any issues that came up in the testing. Even now very few people have actually tried working with svn -- the repository revision has increased by less than ten revisions since I originally checked out the tree a few days ago. - Tobi (Disclaimer: I've been using svn a little before the test repository was set up, but only on very small projects, nevertheless I heavily used tags there simply because it was so easy compared to cvs)
