Stephan Menzel wrote:
Hi Hartmut,
On Sat, Mar 17, 2012 at 8:11 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
As far as ToroiseSVN is concerned this is not entirely true. TortoiseSVN exposes not only _all_ of the usual commands svn supports (at least I have not stumbled over anything I couldn't do), but additionally has more functionality (blame view, logs dimming already merged revisions, etc.) and often a more convenient way to present the generated outputs (I'm not sure if TortoiseGIT has reached this level of maturity).
In my opinion it has not. I have tried to get windows users on board by using TortoiseGit to ease transition to git and it did more harm than good. On the pro side it has an awesome UI and integration and the features you have mentioned but on the downside it is loaded with bugs, sometimes severe ones. I have discouraged the team from using it. Also, it has the problem of using and propagating SVN semantics and terminology to the point of trying to look like TortoiseSVN to pretend little has changed instead of embracing and understanding the change. An example that struck me hard back then would be "revert". A git revert is an entirely different thing than a svn revert is. Users have to learn this to prevent accidents. And yet TortoiseGit offers a 'revert', doing what an svn revert would do (more like a git reset --hard or a git checkout), but beneath the hood of course does the git equivalent. So it works, but such a new git user will one day discover the hard way that a revert is not what he or she always thought it was.
I'm generally not that interested in one system vs the other - I just don't like to mess with anything that works well enough - as SVN does in my view. But I have to accomodate those I work with and just last week I had to install GIT on my system and sync up with the repo at a customer's site. I installed the Tortoise package, expermented for an hour or so with a local repo, read some of the documentation. This was enough to make the difference in the revert obvious to me. I then checked out the customer's repo, added my part commited and pushed to the customers repo and asked them to verify that I did it all correctly - which I had. Had to do a few tweaks - auto cr/lf etc. But basically the whole process was smooth as silk. Now I have both system on my machine SVN and GIT because different customers use different systems. If I right click a folder which is controled by GIT I get the git menu while if I right click a folder controlled by SVN I get the svn menu. As I said this whole thiing works slick as snot with a minimum of pawing through the svn/git documentation. note that this documentation for both systems is all there in an easily readible form. If you've been using Tortouise SVN you'll immediatly feel at home with Totoise GIT (maybe too comfortable as the above author aledges). I suppose there are host of differences but from my stand point it just comes down to Git has a "two stage" process because there is a local repo as well as a remote one. "commit" is local, "push" is for the remote one. The local "commit", "revert", etc are much faster than SVN's remove versions SVN just has the remote one. Given my personal experience I really can't see how all these bits have been spilled in the discussion. I'm thinking that there's an inverse proportion between the number of bits spilled on a topic and the importance of the topic itself. To summarize: If you're using TortoiseSVN, you'll feel totally comfortable with TortoiseGIT in a very short time. It seems to me that consensus of the boost "heavy lifters" who are responsable for actually getting the work done that they want to move to GIT. As I'm generally of the view that he does the actual work should have the final say in how the work gets done, I think they should feel free to transition to GIT at their convenience. Robert Ramey