Hi! On Tue, Jun 23, 2009 at 08:11:42AM -0400, Kenneth R Westerback wrote: >[...]
>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 ...). >.... Ken Kind regards, Hannah.
