Subject: Re: [boost] [git] What's the IDE picture like?
From: Pedro Larroy (pedro.larroy.lists_at_[hidden])
Date: 2012-03-27 12:05:41
I would recommend to use mercurial, we have been using it in
production in Nokia for one year and the experience has been good.
It's relatively easy and intuitive to use, with good tools and user
interfaces for the major platforms.
I would strongly recommend it.
On Tue, Mar 27, 2012 at 6:59 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Stephan Menzel wrote:
>> Hi Hartmut,
>> On Sat, Mar 17, 2012 at 8:11 PM, Hartmut Kaiser
>> <hartmut.kaiser_at_[hidden]> 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
> 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
> 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
> in a very short time.
> It seems to me that consensus of the boost "heavy lifters" who are
> for actually getting the work done that they want to move to GIT. As I'm
> of the view that he does the actual work should have the final say in how
> work gets done, I think they should feel free to transition to GIT at their
> Robert Ramey
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk