Ferenc Kovacs wrote:
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
None of them yet support some of the code management and merging tools like
BeyondCompare inside Eclipse, but even that is coming along nicely.
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.
I know that there are problems with Eclipse, but I've never hit them myself, and
all of my PHP code goes through phpeclipse, as does the majority of rest of my
code editing on every other language.
Off topic - I'd be interested to know what your problems were? I've used
BeyondCompare since long before starting to use Eclipse, and that still works
better for me than some of the other options in 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.
Then can we at least hold fire until some of the more glaring problems are fixed
- such as egit not supporting submodules ...
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.
So you have never had problems appearing in one platform that are not present in
the other? I clone from a single master on a Linux box, but even the working
machines are now managed from clones of my master repo base. Since I could not
even run the same command line stuff in windows and linux git a year ago, a lot
of time was wasted that would have been better spent developing ... Not much of
my C code is developed cross platform, but everything else simply has to work on
both, and why would I use different methods for some things - which was the
point about the 'help manual' I do the same thing at the moment, but there is no
way to do that with a git base.
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.
Look closer ....
TortoiseHg is very much cross platform and works as well with Nautilus as it
does with Windows Explorer ... and is even packaged with a number of Linux
distributions.
It is specifically designed to work the same on both!
And with hggit hooked up it handles github - as long as the repo is simply too
big - such as libreoffice - or has too complex a submodule structure.
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. :/
And the original project that I was trying to handle is some 200 submodules. I
ended up writing scripts to clone the set I needed for each target - and _still_
have to manually commit each module to github.
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 it worked then it might be - but for a large number of development setups it
simply doesn't work. The options were fairly evenly matched so the coin that won
was the 'github has a bigger user base than bitbucket' - and nothing much else :(
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.
I understand the reasons for some need to change - as I said I'm running hg here
for much the same reason. I have no doubt that the objections I have to git will
be totally ignored because very few of us are using Eclipse as a development
platform, but breaking down the code base to make it more modular would be an
easy step and bring things more in line with how many of the distributions work
anyway? Allowing fixing of a single module such as the problems with 5.3.7/8/?
or ignoring it if we simply never enable it. But making a huge repo like the
libreoffice one makes cross working almost impossible. So in my book, the git
camp can have their way if they are a little flexible in making cross dvcs
working better. Personally I never install MySQL therefore I end up manually
building PHP simply to prevent the package manager re-enabling it, and that is
necessary on Windows as well as Linux ... hence the cross platform development
process - which I am already managing via hg.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
