Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E591980.4090405@lsces.co.uk>
References: <slrnj5appg.6vi.dsp@experimentalworks.net>
	<CAJW__o3+=Bai6xj2fR7dNdZVn60WW=RKzBCO3k+HBvo8V7R-fw@mail.gmail.com>
	<4E56E068.8030502@gmail.com>
	<4E5741CE.4000809@lsces.co.uk>
	<CAFt2z-kCX=jCzWW+LUPuGf50+gLuh8F9HKz3fFuOR+7bBPz1Zw@mail.gmail.com>
	<CAKUjMCUZoig=uF60uKzLz7LDPbrhq6UQxDm=TqnPU4YKoSxHSQ@mail.gmail.com>
	<4E591980.4090405@lsces.co.uk>
Date: Sat, 27 Aug 2011 19:33:16 +0200
Message-ID: <CAH-PCH5h1iKi4F2Oa19=_XddGSU=DWXxoxp7V=hhH8jJt8AEKQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Choosing a distributed version control system
 for PHP
From: tyra3l@gmail.com (Ferenc Kovacs)

> 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 m=
any
> 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 platf=
orm
> 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 i=
n
> 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, b=
ut
> 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 stil=
l
> 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=3D314853
http://code.google.com/p/nbgit/issues/detail?id=3D38 (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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu