[git] What's the IDE picture like?
All this talk about switching to git brings up one important question for me, and I suspect others.. Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned.. What is the process for a user that wants to do their development, including version control, like? Specifically what does an: * Eclipse user do? * Xcode user do? * VIsualStudio user do? I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 16 March 2012 17:01, Rene Rivera <grafikrobot@gmail.com> wrote:
All this talk about switching to git brings up one important question for me, and I suspect others..
Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned..
If git-flow is used (and that's a big 'if'), you'll probably need to use the command line to do various operations.
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do?
* Xcode user do?
Git is integrated into xcode 4.
* VIsualStudio user do?
There seems to be a couple of options: http://stackoverflow.com/questions/507343/using-git-with-visual-studio
On Fri, Mar 16, 2012 at 12:25 PM, Daniel James <dnljms@gmail.com> wrote:
On 16 March 2012 17:01, Rene Rivera <grafikrobot@gmail.com> wrote:
All this talk about switching to git brings up one important question for me, and I suspect others..
Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned..
If git-flow is used (and that's a big 'if'), you'll probably need to use the command line to do various operations.
Well.. That's what I was afraid of.
What is the process for a user that wants to
do their development, including version control, like? Specifically what does an:
* Eclipse user do?
I've used it.. But I was hoping more for a "here's how to do the git-flow equivalent in the base GUI tool".
* Xcode user do?
Git is integrated into xcode 4.
I've used the svn integration.. And if that's any indication of the extent of the git integration I don't look forward to that. I guess the overall point I'm trying to say is that we have to think about the fact that people will want to use what they are familiar with.. And no amount of cajoling will change that. Just like no one used the manual svn-merge tool when suggested (before it was integrated into svn). So I'm reticent to require processes that require not generally available steps/scripts/commands. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Fri, Mar 16, 2012 at 1:01 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
All this talk about switching to git brings up one important question for me, and I suspect others..
Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned.. What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
http://www.youtube.com/watch?v=efS0kKvfi6k But do consider TortoiseGit too. It is compatible with TortoiseSVN, and you can run both at the same time without problems. While integration with an IDE has advantages, integration with Windows Explorer is handy too.
I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI.
One of the pluses for Git is that the community is so active. That includes integration with just about anything that a version control system can be integrated with. --Beman
Rene Rivera wrote:
All this talk about switching to git brings up one important question for me, and I suspect others..
Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned.. What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI.
I can shed some light on this as far as windows is concerned. I'm not really all that interested in the finer points of source control systems. I generally use the simplest functionality. Once in a while I branch or tag but that's about it. When boost converted to SVN I installed the client on my system along with Tortois SVN which enhances the windows file dialog with ability to do the svn functionality by right clicking the file icon. Those files which are under controls of the svn system are distinguised by an overlay on the file icon. This turns out to work quite well and I've been very pleased with it. SVN is a little slow and a little clunky for some infrequently used operations but in general it does the job pretty painlessly for this environment. Last week, I took on a new customer who uses GIT. OK loaded windows version on my machine along with TortiousGIT. This results is a setup which is almost identical from a user standpoint as the TortoiseSVN set up. The workflow is almost identical - at least for the common operations. The icon overlay and right click intereface is the same. So, I've reached the point where I don't care whatever is decided. Or, more accurately, I've been able to maintain my position of not having to care about this. I've sure there are differences but in my day to day work I don't really see a lot of them. But then I make an effort to keep things simple - maybe that's why I don't see a huge problem here. Robert Ramey
On 16/03/12 18:01, Rene Rivera wrote:
All this talk about switching to git brings up one important question for me, and I suspect others..
Given all the various git-flow, git-this, git-that, git-whatever, tools that are getting mentioned..
Those are just tools that formalize a given workflow. None of them is necessary.
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
Xcode and Eclipse support git natively. You'll have to get a plugin for Visual Studio.
I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI.
While most GUIs claim to be able to allow everything the original command-line utility can do, in truth they are more suited to simple tasks, more complex ones being better done with the real thing.
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
Xcode and Eclipse support git natively. You'll have to get a plugin for Visual Studio.
...which would be a pain if a certain workflow is mandated by the new Boost policies to be developed...
I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI.
While most GUIs claim to be able to allow everything the original command-line utility can do, in truth they are more suited to simple tasks, more complex ones being better done with the real thing.
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). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Hartmut Kaiser wrote:
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
Xcode and Eclipse support git natively. You'll have to get a plugin for Visual Studio.
...which would be a pain if a certain workflow is mandated by the new Boost policies to be developed...
I ask because I'm really tired of learning yet more command lines tools at this stage in my life. And even though all GUI tools have drawbacks they do have the advantage that they condense the workflow usages to something understandable. And I would be really hard pressed to use any new version control system that I can't use a GUI. And preferably an integrated GUI.
While most GUIs claim to be able to allow everything the original command-line utility can do, in truth they are more suited to simple tasks, more complex ones being better done with the real thing.
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).
Well, I think we can all agree that TortoisSVN is "good enough" in it's presentation of SVN facilities. I'm arguing that TortoisGIT is "good enough" to support GIT for those of us who don't want to lean a whole new command set. I've been using it a couple of days and from my "user's" perspective - it's not all that different. So I'm going to guess that as far as windows users are concerned, there many, if any, who would care which system boost uses. Robert Ramey
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Mar 17, 2012 at 8:11 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
Xcode and Eclipse support git natively. You'll have to get a plugin for Visual Studio.
...which would be a pain if a certain workflow is mandated by the new Boost policies to be developed...
What, exactly, would be a pain? Olaf
On Sat, Mar 17, 2012 at 8:11 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
What is the process for a user that wants to do their development, including version control, like? Specifically what does an:
* Eclipse user do? * Xcode user do? * VIsualStudio user do?
Xcode and Eclipse support git natively. You'll have to get a plugin for Visual Studio.
...which would be a pain if a certain workflow is mandated by the new Boost policies to be developed...
What, exactly, would be a pain?
If you ask me, GIT itself is the pain as it is a major usability catastrophe, but that's pure IMHO. But to answer your question: If Boost decides to go for a tool mandating a certain workflow, then any IDE tool will most certainly not support that directly, leaving IDE users out in the cold as they have to 'emulate' the mandated workflow themselves. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
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. Cheers, Stephan
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
Hi 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. Pedro. On Tue, Mar 27, 2012 at 6:59 PM, Robert Ramey <ramey@rrsd.com> wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (9)
-
Beman Dawes -
Daniel James -
Hartmut Kaiser -
Mathias Gaunard -
Olaf van der Spek -
Pedro Larroy -
Rene Rivera -
Robert Ramey -
Stephan Menzel