>>[...] > >>To assume that it is not superiour in the particular application >>to which it is being put is also ridiculous. Having 1000 extra >>features you don't use and will never use is not an advantage. > >If one hasn't tried it out, it's difficult to assume one would never use >features like disconnected operations (devs on planes), local/inofficial >branches (devs working on new features that aren't ready for prime time >yet; "I'm committing this, disconnected from the build, so others can >work on it" wouldn't be completely necessary either, for example, if >one could share experimental branches using a dvcs). > >But even for traditional operations... I'm for example hooked on the >mere speed of git compared to svn or cvs even for a not so big tree >like a private web project. And even for that I use the fact that both >repositories are equals. At home, I commit to the local repository on >the home box. Elsewhere I might remote-login to a leased server where >another repository lies (and where also the http server is, using a 3rd >copy which always is on the "public" branch, while the other >repositories also have other branches). Or I might temporarily clone the >repository from the leased server, work locally (perhaps doing more >than one revision), then push the work (in one hunk!) back to the leased >server and publish (i.e. update the public branch to the http server's >directory). Especially over slow lines, definitely an advantage over >having only one central cvs/svn repo on the leased server and only >working copies on the other boxes. Local operations are *fast* (e.g. >switching from one branch to another with git checkout, >compared to cvs up -r... for switching the branch or svn switch or ...).
Blah blah blah blah You just like listening to yourself talk. Shut up.
