> I use CVS and SVN directly from Eclipse and I know exactly where you are > coming from. Currently this all runs transparently on all platforms and many > of the 'reasons' given for wanting to change are already supported by > additional tools _in_ Eclipse.
http://eclipse.org/egit/ http://www.javaforge.com/project/HGE http://wiki.bazaar.canonical.com/BzrEclipse using the vcs from your IDE, or outside(either via gui or command line) is a personal preference, for example I had problems with the SVN intergration in Eclipse, so I tend to use it outside of Eclipse. At least before I ditched eclipse. > Up until recently DVCS systems did not have > such will integrated support, and this was the cause of most of my own > problems. this has nothing to do with DVCS, usually new tools lacks support from the third parties at first. > Having machines running both Windows and Linux in parallel for > testing purposes I certainly don't want to be having to think which platform > I am on and changing the help manual! you don't necessarily need to edit the code on the different platforms, only build and run it, but having a platform independent development environment is a good thing. > > TortoiseHg provides an independent integrated GUI which I currently use in > parallel with Eclipse to support Hg and git via hggit, but it lacks some of > the nice features of the SVN integration. MercurialEclipse has made a lot of > progress in the last few months and is starting to mimic the SVN tools, but > still has a few rough edges. Certainly it's developers are targeted at > making that better. tortoisehg (and tortoisegit) are windows only afaik, so if cross platform compatibility is important to you, I can't see how can you use those. > > The Git GUI support is considerably more disjointed. Nothing is available > that works transparently cross platform! The EGit plugin for Eclipse still > does not support submodules and is rather basic in it's other functions, but > now that I have my Eclipse/TortoiseHg setup working something like stably, I > am actually _almost_ back to the same functionality that I've had on CVS and > SVN repo's for many years, and on the whole can just access github and > gitorious via that. yeah, the git submodule support for IDEs sucks: https://bugs.eclipse.org/bugs/show_bug.cgi?id=314853 http://code.google.com/p/nbgit/issues/detail?id=38 (Netbeans) http://youtrack.jetbrains.net/issue/IDEA-64024 and the fact that the minority of the git users prefer the command line over the guis doesn't help the issue. :/ > > The jump to git by many projects had nothing to do with improving > functionality and everything to do with jumping on 'this is the new > sourceforge' bandwagon. The majority of the world uses Windows - it does not > mean it's the right answer to the problem ;) > didn't occurred to you that maybe the developers behind those project take those concerns into account, and they chose git because it was worth it? if you think that for your own projects SVN or even CVS is better choice, then use those! but for the php project, we have to find the best possible solution suited for those who will be actually using the version control. our current problems with svn are pretty much laid out in the rfc https://wiki.php.net/rfc/dvcs I would add the fact that our current repo is pretty large(both in data size and in history), so on a few occasions when I tried to merge, or reverse merge, that was surprisingly slow. Another thing which is not explicitly explained just implied: having the ability to commint on your local clone also means that we could keep the "blessed" repository more clean. here is an example: http://news.php.net/php.pecl.cvs/16388 currently we have to keep patches around for contribution, with dvcs, we could make the collaboration more fluent. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
