Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.
Votes can be found here:
https://wiki.php.net/rfc/dvcs/vote
The RFC can be found here:
https://wiki.php.net/rfc/dvcs
Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm.
- David
Hi!
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.
I'm not sure choosing DCVS by vote is actually a good way to go here. I
think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we don't
have people committed to making it happen majority-based vote is useless
IMHO.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting
on the DVCS RFC. If you think something is missing or should be
explained in more detail, let me know.I'm not sure choosing DCVS by vote is actually a good way to go here.
I think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we
don't have people committed to making it happen majority-based vote
is useless IMHO.
Sure. I wrote the RFC because I plan to implement it. I will make it
possible for either Git or Mercurial, but as stated, I prefer doing it
with Mercurial.
The vote is not a 100% we do it, but rather a: we would like to have it
that way. So if people choose Bazaar, someone has to come up with a
solution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOVWrAAAoJEAT0aMuPE7Z1W0EQAK59Xw/gvwLI4qhR7pZ/kuJQ
d4+Qs3wP2jipZUtq+6STvZdPD1Yf9PgyM9O+nshF73VtM91gY259CQ62QrDIE/6X
mKes7T+3WWdQoEbKPCBA2uYiriVT2feS9DpiZnkz8oarXgFwRy+iryEeLGxCSovt
Swy0xvpM1V6zt1ZxgYMhQDKF3eJCd7K6DctKyNScwzqH2N41HFnR/bhk1ZOT172B
e/qXy3Bw0k3jo6khq2bjPlAID1yecmVuHjxtx5sxX/cTkyfrUWeYcUU49BIFRHa5
ZZe9JyfO2HcTi2+V5ni097Q2FYOOV7CuLdMaZqf26L0oZIttn+3CSNTcw+77cE98
aNB9+n1vkXPBuVpyz0mZz2/BYHpX4SjPHdgmmgZHlA9xz8RRbYypyK1TraoCiVOO
86utV3+TAsat+zl4hkvbtLap0VO6/9/XuFLdkKzhjMpP+8LkXo/5/supP2oyoYrP
rHNyvdiH8gV6fQQyXoikSxYaCtLrAVwoC6mc8OIIQsiT0INkB5tP5g9hbuh+uxO2
nFT5qgYDhkXbNDYG7qHFGH29ijjARcer0NYekUtnZvViC3PGQ4vEZhDvjcis8uDr
LrqzD3surZJX4CLUF0i13TKiNS9S8s/orV9zdI93I18gFXf6wAPPUZJUXVLsgSic
+Gir6bAS7NVZs73KtoFL
=5Hhp
-----END PGP SIGNATURE
David Soria Parra wrote:
I'm not sure choosing DCVS by vote is actually a good way to go here.
I think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we
don't have people committed to making it happen majority-based vote
is useless IMHO.
Sure. I wrote the RFC because I plan to implement it. I will make it
possible for either Git or Mercurial, but as stated, I prefer doing it
with Mercurial.The vote is not a 100% we do it, but rather a: we would like to have it
that way. So if people choose Bazaar, someone has to come up with a
solution.
I think the problem here is that if the majority are already committed to git
anyway, those of use who are using hg or something else are going to be at a
disadvantage since it is now obvious that cross working will not work especially
if everything is rolled into the one super repo.
Even the 'decision' to roll everything into single repo copying the current SVN
history should be something that is put to a vote. The problems of testing
sections of this vast code base and tracking bugs against them should be a
perfect reason for a much more modular approach so we can test each module as a
separate package. And the process is something that does change depending on
the different DVCS's. So simply voting on the current rfc seems a little
pointless at the moment?
--
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
David Soria Parra wrote:
I'm not sure choosing DCVS by vote is actually a good way to go here.
I think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we
don't have people committed to making it happen majority-based vote
is useless IMHO.
Sure. I wrote the RFC because I plan to implement it. I will make it
possible for either Git or Mercurial, but as stated, I prefer doing it
with Mercurial.The vote is not a 100% we do it, but rather a: we would like to have it
that way. So if people choose Bazaar, someone has to come up with a
solution.I think the problem here is that if the majority are already committed to git
anyway, those of use who are using hg or something else are going to be at a
disadvantage since it is now obvious that cross working will not work especially
if everything is rolled into the one super repo.
Those wanting to use git and git workflows have a disadvantage when we stay with SVN.
Choosing a VCS happens from time to time and sometimes your favorit is not the winner.
I personally would love to see PHP moving to hg, but if more people like git more, the
hg people have to deal with it.
Even the 'decision' to roll everything into single repo copying the current SVN
history should be something that is put to a vote. The problems of testing
sections of this vast code base and tracking bugs against them should be a
perfect reason for a much more modular approach so we can test each module as a
separate package. And the process is something that does change depending on
the different DVCS's. So simply voting on the current rfc seems a little
pointless at the moment?
The RFC points out that there will be modules. We will not copy the current SVN
history into one big repo. In fact having everything, pecl, php-src and co in one
repository does not make sense.
Those wanting to use git and git workflows have a disadvantage when we stay with SVN.
Choosing a VCS happens from time to time and sometimes your favorit is not the winner.
I personally would love to see PHP moving to hg, but if more people like git more, the
hg people have to deal with it.
Agreed on both counts.
The RFC points out that there will be modules. We will not copy the current SVN
history into one big repo. In fact having everything, pecl, php-src and co in one
repository does not make sense.
The original plan called for the SVN repo to be split up at some point
in the future, but DVCS gained traction and SVN went without any
attempts by anyone to put a proper workflow of any kind in place.
-- Gwynne
Gwynne Raskind wrote:
Those wanting to use git and git workflows have a disadvantage when we stay with SVN.
Choosing a VCS happens from time to time and sometimes your favorit is not the winner.
I personally would love to see PHP moving to hg, but if more people like git more, the
hg people have to deal with it.
Agreed on both counts.
It is nice to see that I am not alone in preferring hg ...
Sometimes it does seem that I'm in a minority of 1.
The RFC points out that there will be modules. We will_not_ copy the current SVN
history into one big repo. In fact having everything, pecl, php-src and co in one
repository does not make sense.
The original plan called for the SVN repo to be split up at some point
in the future, but DVCS gained traction and SVN went without any
attempts by anyone to put a proper workflow of any kind in place.
And I think this is the point.
With the right structure in place then it will be easier for cross dvcs
working. The current plan calls for all of php-src to be a single repo, with
rules for moving extra modules in and out. That is the single repo I am
referring to and potentially it will be as unwieldy as the libreoffice setup? It
is about time that splitting things up was considered in a little more detail
so we can work on every module with the same ease as 'extra' extensions are now
currently managed? Even the argument that one needs to see all the history at
once has the alternative view that just seeing commits for a single module would
be helpful?
( Note Pierre - I'm not using upper case for emphasis - I started text messaging
when the printers only had upper case so I'm still learning these newfangled
ways :) )
--
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
Hi!
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.I'm not sure choosing DCVS by vote is actually a good way to go here. I
think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we don't have
people committed to making it happen majority-based vote is useless IMHO.
I think that David is the most commited person for this cause, and
currently he is the ?only? one who actually does something for the
progress.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. Â If you think something is missing or should be explained
in more detail, let me know.I'm not sure choosing DCVS by vote is actually a good way to go here. I
think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we don't have
people committed to making it happen majority-based vote is useless IMHO.I think that David is the most commited person for this cause, and
currently he is the ?only? one who actually does something for the
progress.
There are people behind the scene like Gwynne, Johannes, Rasmus, Pierre
and Nils Aderman from phpBB who helped. Just wanted to mention their
names at least once :)
Hi!
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.I'm not sure choosing DCVS by vote is actually a good way to go here. I
think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we don't have
people committed to making it happen majority-based vote is useless IMHO.
It is the same for everything, that does not make the vote useless.
About people maintaining our infrastructure, not much actually
maintains svn, and that won't change anything if we move to something
(except easiness) from a backup&co pov.
And unlike the last time we switched to another VCS, this time we will
have a clear decision process :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be
explained in more detail, let me know.I'm not sure choosing DCVS by vote is actually a good way to go here.
I think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we
don't have people committed to making it happen majority-based vote is
useless IMHO.
I agree, and I also think that before people can make a choice they need
to have played with all the options. Just picking "git" because that's
what you heard of and what all the fan boys like is not the correct
way to go. In order to make a choice, and even consider switching away
from SVN, something that works just fine, you need to know the systems
(ie, git and hg).
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be
explained in more detail, let me know.
I'm not sure choosing DCVS by vote is actually a good way to go here.
I think we need much more input from people that maintain all the
infrastructure we're using now and would be doing the move. If we
don't have people committed to making it happen majority-based vote is
useless IMHO.
I agree, and I also think that before people can make a choice they need
to have played with all the options. Just picking "git" because that's
what you heard of and what all the fan boys like is not the correct
way to go. In order to make a choice, and even consider switching away
from SVN, something that works just fine, you need to know the systems
(ie, git and hg).
+10.
I think a vote is prematured right now.
Cheers.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 24 Aug 2011, Stas Malyshev wrote: I agree, and I also think
that before people can make a choice they need to have played with
all the options. Just picking "git" because that's what you heard
of and what all the fan boys like is not the correct way to go.
In order to make a choice, and even consider switching away from
SVN, something that works just fine, you need to know the
systems (ie, git and hg).
+10. I think a vote is prematured right now.
so what do you suggest? We talk about the topic for 3 weeks now, and I
think waiting any longer will not make more people familar with HG. So
how do you make people take a look at the VCS in question? I'm open
for suggestions.
People now have 2 weeks to try out PHP by using the mirrors from either
git.php.net or hg.php.net and see how their favourite system works. For
me it seems most people don't even read the RFC and the recommendation,
so I don't expect them to try out the VCS, but I don't have a clue how
to change it.
Joking: Next time I'll add a survey that you need to complete
successfully before being alllowed to vote ;).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOVhfNAAoJEAT0aMuPE7Z1zukP/2IrTehCAE2AU+3CFSwh05NI
san2ncCOfk3tdn6zOuc+4rYGWfSfixqjC0Xre7nma8sRb14zRt1kpzB5xA6EL2i9
SgqfPEUcpzPAF5QkoNrnR9FnZfFK/y/QXTRaupdk/ApLg2rdwegG2BzdB5AiofN7
Q1kxTlVBnwlizPH4J/0/H0kzm9/spkRhWkXslVtvkhVy/7yZH7I7R8kd+voy+6bE
jmYuI7hS4Jf2/T0OFA9Js2V3sopOwOy7tuutEUqZ30EXjrE0UKFGs9eiGuBJaMF3
MLgvlSa6tcaAD+yJ8tLraJ1awUNl29kPT2QTJZQkgkJ07iKqPjipJu5jYRLQ6qdy
kPuec7gUWC4jzrdmCsvtB1fdEGKWiCXspnP0KgGXjVmqreSvZBabiZm0fOEHqHST
foqV7weQe/4wZd3n8UxTsk/Pd27OU5uXllkApsy123d7rV0hv9CEPy5WI7nlWsnB
+necXTfdUeOFV2Vdgw7mDPXxf5vIC6t/rXiO2UjGd0QUZz9rxnb+JjQ5CAIpgeZz
JVqXJH0RbVa7rIcxBctRmvZ/qq9oEQ9C4Du5vCSr8vOW7PKFJUo7QODd9cDbtBsS
0TnX8diqpw1JaXblIKrYmsUANkIiHLpynT3W9SZeCqdUjt8weiF8xAxbJKkA9/Tj
ZE87iAbx3L+GfGNJ5ayz
=Q5uu
-----END PGP SIGNATURE
On Wed, 24 Aug 2011, Stas Malyshev wrote: I agree, and I also think
that before people can make a choice they need to have played with
all the options. Just picking "git" because that's what you heard
of and what all the fan boys like is not the correct way to go.
In order to make a choice, and even consider switching away from
SVN, something that works just fine, you need to know the
systems (ie, git and hg).
+10. I think a vote is prematured right now.
so what do you suggest? We talk about the topic for 3 weeks now, and I
think waiting any longer will not make more people familar with HG. So
how do you make people take a look at the VCS in question? I'm open
for suggestions.
I know. It's a difficult choice.
But if we change our VCS for a DVCS, we do it for contributors or
maintainers? If maintainers are the most concerned people, they should
give a try to Hg and Git for a period longer than 2 weeks (2 months
seems to be a reasonable period, 1 month with Hg, 1 month with Git).
For the moment, the vote is opened to contributors. Maybe it's not a
good “target” for the vote.
People now have 2 weeks to try out PHP by using the mirrors from either
git.php.net or hg.php.net and see how their favourite system works. For
me it seems most people don't even read the RFC and the recommendation,
so I don't expect them to try out the VCS, but I don't have a clue how
to change it.
I don't too. I think Git is more complicated than Hg and I regret the
way the vote is changing. But, I repeat, I think the target for the vote
is not appropriated.
Joking: Next time I'll add a survey that you need to complete
successfully before being alllowed to vote ;).
s/Joking/Todo/ :-)
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
2011/8/24 David Soria Parra dsp@php.net:
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.
I won't transfer the discussion over here but; I don't want to move to
a new system we we did it just a few years ago, as Rasmus said long
before we moved was that we want to find a solid system that could
hold out just as long as the old setup. I don't have a problem by
using SVN, nor merge as we have been good at keeping files in sync so
its easy to merge patches, much easier than the old unicode-trunk.
That being said; I agree with Stas that having a vote is not a good
way to actually make a choice here, but it gives a hint of those that
voted, as I'm sure that there are many more actively working on the
project like PEAR. PECL and Doc guys thats not gonna vote because they
don't follow Internals.
But -1 from me.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2011/8/24 David Soria Parra dsp@php.net:
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.
I won't transfer the discussion over here but; I don't want to move to
a new system we we did it just a few years ago, as Rasmus said long
before we moved was that we want to find a solid system that could
hold out just as long as the old setup. I don't have a problem by
using SVN, nor merge as we have been good at keeping files in sync so
its easy to merge patches, much easier than the old unicode-trunk.That being said; I agree with Stas that having a vote is not a good
way to actually make a choice here, but it gives a hint of those that
voted, as I'm sure that there are many more actively working on the
project like PEAR. PECL and Doc guys thats not gonna vote because they
don't follow Internals.But -1 from me.
FWIW, PEAR is already moving to GitHub.
David
David Muir wrote:
FWIW, PEAR is already moving to GitHub.
So who dictated that ....
There should at least be a little consistency in PHP and this is just another
example of everybody just doing what they want and sod the rest of us :(
--
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
David Muir wrote:
FWIW, PEAR is already moving to GitHub.
So who dictated that ....
There should at least be a little consistency in PHP and this is just
another example of everybody just doing what they want and sod the rest of
us :(
the pear group decided that obviously.
btw. I thought that only the pear2 infrastructure (site, packages) are
moving to github.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
David Muir wrote:
FWIW, PEAR is already moving to GitHub.
So who dictated that ....
There should at least be a little consistency in PHP and this is just
another example of everybody just doing what they want and sod the rest of
us :(
PEAR is very different than the core. PEAR is inherently split up into
small sub-packages that are easily maintained using separate version
tracking. You could say PEAR is much like PECL, but there are still
plenty of differences. We have a group of elected officials which
(mostly) make final decisions, and we also have many individual
developers that like to do what they want with their libraries.
PEAR developers have long been able to use other publicly available
version control systems. Yes the main repo has been with PHP, until
svn.pear.php.net was set up for PEAR2 and subsequently moved back to
PHP infrastructure once svn.php.net was set up.
Just in the past few months or we've moved all of PEAR2 to git, and
PEAR packages are individually moved over at will.
the pear group decided that obviously.
btw. I thought that only the pear2 infrastructure (site, packages) are
moving to github.
PEAR2 was the first, yes.
For PEAR(1) our QA team has focused on unmaintained packages. It takes
a lot of manpower to vet new contributors by requesting patches and
building enough trust that we're OK granting them svn.php.net access.
We've recognized that it's easier to get new/external contributions on
github, which is very important when maintainers leave and our QA team
has to take over.
--
Brett Bieber
The only think that worries me is that most of the time people choose the
service and not the tool.
On one hand you have Mercurial, a more than capable DVCS with the lowest
barrier of entry IMHO (you will love it while you learn it), and the very
good service that is Bitbucket, now kind of catching up to github (but not
there yet). However, Bitbucket doesn't have —AFAIK— the quantity of users
github has, and that would be extremely healthy for the project.
On the other hand you have git, which is a very popular and powerful DVCS,
however (you will pull your hairs out while learning it but will love it in
the end) it is not as straight-forward to get working as Mercurial. Having
current SVN-only contributors learn it might going to be quite a challenge.
If I could vote I'd vote for mercurial, but then again, I bet having PHP on
github will increase contributions very quickly.
Damn.
David Muir wrote:
FWIW, PEAR is already moving to GitHub.
So who dictated that ....
There should at least be a little consistency in PHP and this is just
another example of everybody just doing what they want and sod the rest of
us :(--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://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<http://www.firebirdsql.org/index.php
If I could vote I'd vote for mercurial, but then again, I bet having PHP on
github will increase contributions very quickly.
which is pointless if we can't easily accept/merge the pull requests
from the github clone. :/
git itself is a powerful tool, but as AFAIK most of the people in this
thread only prefer it over git if we also can use the github.
maybe it would be a good idea to split up the dvcs migration to
smaller steps (so different part of the current svn repo could be
discussed/voted separately), and I also think, that it would be a good
idea to create a poll for the current developers:
- which vcs are you familiar with
- which vcs would you prefer to use for your current work on the php project
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
which is pointless if we can't easily accept/merge the pull requests
from the github clone. :/
You can very easily accept pull requests from GitHub even if you're not
working on GitHub.
e.g. I've been working on my own PHP fork, and have submitted a pull
request to the PHP project. My repo is at
https://github.com/rmccue/my-php-fork in the master branch.
$ git remote add github-rmccue git@github.com:rmccue/my-php-fork.git
$ git fetch github-rmccue
$ git merge github-rmccue
$ git push php-src master
The only difference as far as pull requests go is the one-click
interface on the GitHub site (which I don't like personally, since you
can't test before pushing).
Ryan McCue
<http://ryanmccue.info/
Ferenc Kovacs wrote:
- which vcs would you prefer to use for your current work on the php project
- which vcs will you continue to use what ever anybody else thinks you should be
using?
I'm running hg into github transparently for those projects that have already
jumped lemming like ... and I put up with the crap that results from it :)
I don't see github as any advantage, just a complete stranglehold on those parts
moved to it, which will not then integrate with a decent project infrastructure
such as php ALREADY HAS!
--
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
Having current SVN-only contributors learn it might going to be quite a challenge.
That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).
I recently worked with some mac users and they were a little jealous
of that ability. I point and click and commit from my explorer.
I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.
With SVN, things feel pretty simple. I don't currently "get" git. It
SEEMS very complicated for no gain - when all I'm working on is 1
extension (pecl/win32service) and phpdoc.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
there is the same for git. Even most IDEs have plugin for git support
these days. Lack of GUI is definitively not an argument.
Having current SVN-only contributors learn it might going to be quite a challenge.
That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).I recently worked with some mac users and they were a little jealous
of that ability. I point and click and commit from my explorer.I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.With SVN, things feel pretty simple. I don't currently "get" git. It
SEEMS very complicated for no gain - when all I'm working on is 1
extension (pecl/win32service) and phpdoc.--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Having current SVN-only contributors learn it might going to be quite a challenge.
That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).I recently worked with some mac users and they were a little jealous
of that ability. I point and click and commit from my explorer.I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.With SVN, things feel pretty simple. I don't currently "get" git. It
SEEMS very complicated for no gain - when all I'm working on is 1
extension (pecl/win32service) and phpdoc.
you should check out tortoisegit then.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Richard Quadling wrote:
Having current SVN-only contributors learn it might going to be quite a challenge.
That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).
I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.
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. Up until recently DVCS systems did not have such will integrated
support, and this was the cause of most of my own problems. 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!
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.
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.
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 ;)
--
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
Lester Caine lester@lsces.co.uk writes:
Richard Quadling wrote:
Having current SVN-only contributors learn it might going to be quite a challenge.
That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).
I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.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. Up until recently DVCS systems did not have such will integrated
support, and this was the cause of most of my own problems. 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!
Why would you need to change any manuals? You follow a procedure and the
user decides which client he wishes to perform those procedures and to
interface to the chosen vcs.
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.The Git GUI support is considerably more disjointed. Nothing is available that
works transparently cross platform! The EGit plugin for Eclipse still
does not
gitk does for a start. or?
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.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 ;)
The jump to git was nothing to do with a bandwagon. Its to do with the
fact its fast, practical, well supported and efficient and supports
distributed development as a core feature. To ignore it in favour of
some klunky "established" system like the god awful svn would be to miss
an opportunity to move to what has rapidly become the defacto vcs for
many many people. Arguing that the "gui ui" is a little unwieldy is
silly : it will improve and there are other utilities to handle it. git
works better than any other vcs I have used : it is in active
development and is gaining ground for a reason. As for working
"transparently" cross platform .. How often do you move regularly
between a windows machine and a linux mahine for desktop development?
There are oodles of things that are not the same - one tiny issue with
the desktop integration to git will not kill anyone - and besides,
editors like emacs hide the OS anyway using something like the wonderful magit.
The huge majority of development is done on your local branch anyway.
I guess all I am saying is dont dismiss it because you think its too
hard to use a slightly different GUI interface or that other people only
adopted it because of vogue. People adopted it because it works and
works efficiently and well.
For those that really really dont know about git, listen to Linux
himself:-
http://www.youtube.com/watch?v=4XpnKHJAok8
and/or monitor the #git Freenode irc channel.
Its popularity is nothing whatsoever to do with a bandwagon.
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
There are several decent GUI's for git on the Mac side of things; Github has
even released their own guy.
http://www.git-tower.com/
http://mac.github.com/
http://gitx.frim.nl/
Git tower can be quirky, but you get used to it and the quirks make sense. I
haven't really heard much about mac github. And the last I've heard mixed
about.
But I agree with the previous responders lack of gui support is not a
reason.
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/BzrEclipseusing 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/16388currently we have to keep patches around for contribution, with dvcs,
we could make the collaboration more fluent.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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/16388currently 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
See inline.
Kiall
Sent from a mobile - sorry for being short!
Richard Quadling wrote:
Having current SVN-only contributors learn it might going to be quite a
challenge.That's me. And I am VERY used to TortoiseSVN - a visual tool
integrated into Windows Explorer (not IE, but the filesystem exploring
tool for Windows).
I really don't want to have to work at the command line. Sure I can,
but the tool needs to be a LOT easier than that.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. Up until recently DVCS systems did not have
such will integrated support, and this was the cause of most of my own
problems. 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!
"Supported by tools in eclipse" - to the vast majority of people, this is
useless. I would bet no single IDE / text editor has over 10% share of those
involved with PHP. Choosing your SCM based on a single IDE 'doing it all' is
not a smart move! Ever.
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.
To be honest, this (to me) sounds like you're chasing a dream of one tool to
rule them all. You're negative against TortoiseHg is that it doesn't do SVN
nicely?!?!
What's wrong with using the right tool for the job? Native CLI, or one of
the GUIs.. eg TortoiseHg for HG, TortoiseGit for Git and TortoiseSVN for
SVN.
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.
I'm betting you could have been back to the same, or higher, productivity
levels a long time ago -- if you hadn't been fighting to make the new DVCS
look at feel like your old VCS ;)
Anyway - Re GUIs I've only ever used TortoiseGit, and even than only when
I'm doing windows dev, but it works perfectly. Submodules included. (That is
- unless you try and use it to connect to Hg or TFS or well... anything
other than git!).
And ignoring the current state of play - the GUIs will continue to mature
over time.
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 ;)
If Hg was as significantly better than git as you've been portraying, surely
people would be jumping by the thousand onto the Hg bandwagon?
Now hold on a sec - It's ok to vote to determine the fate of PHP
development - for the entire PHP-lovin' world.
Yet, it's not ok to vote for the handful of developers to collaborate?
Three weeks of discussion (based on what I've seen here on the list)
seems not enough for such a heavy change.
Point in case - it's still being discussed right here; right now. But I
agree with the direction: try the contenders out.
I understand there's complications such as scripts and automation, but I
hope they aren't the reason for impeding progress.
Sticking with a system for 'a long time' results in just as many battle
scars - if not more than keeping up with the times (conservatively).
2011/8/24 David Soria Parradsp@php.net:
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.I won't transfer the discussion over here but; I don't want to move to
a new system we we did it just a few years ago, as Rasmus said long
before we moved was that we want to find a solid system that could
hold out just as long as the old setup. I don't have a problem by
using SVN, nor merge as we have been good at keeping files in sync so
its easy to merge patches, much easier than the old unicode-trunk.That being said; I agree with Stas that having a vote is not a good
way to actually make a choice here, but it gives a hint of those that
voted, as I'm sure that there are many more actively working on the
project like PEAR. PECL and Doc guys thats not gonna vote because they
don't follow Internals.But -1 from me.
On Fri, Aug 26, 2011 at 5:21 PM, Justin Rovang
justin.rovang@minnesota.edu wrote:
Now hold on a sec - It's ok to vote to determine the fate of PHP development
- for the entire PHP-lovin' world.
Yet, it's not ok to vote for the handful of developers to collaborate?
Three weeks of discussion (based on what I've seen here on the list) seems
not enough for such a heavy change.
The discussions actually began when before we moved to SVN without
consensus while a large majority of developers were already in favor
of git.
There will be further discussions about the details of the move but it
is such a small task that we first have to choose the system before we
go further.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
If we do decide to make a VCS change the vote should be fairly one
sided for "option of choice" as this has a fairly broad impact on our
development process.
Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.Votes can be found here:
https://wiki.php.net/rfc/dvcs/vote
The RFC can be found here:
Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm.
- David
I'm fine with git and I think moving to something like that together
with up-to-date tools to contribute (or review patches etc.) will help a
lot.
But I would prefer to keep the (core) infrastructure at PHP internally.
It's just so much easier to integrate tools, add things like hooks for
the bugtracker or whatever.
Having people develop part of a project on github then is surely fine -
but php-infrastructure would still be the "official core" imho.
In this discussion I previously mentioned the TYPO3-community (which I
guess stand for a lot of others) who integrated a review-system based on
gerrit into their forge (actually a RedMine-based system; including
bugtracker etc.) And that integration has helped a lot - both in
openness/ease of use as well as actually "getting the job done".
It looks like the basic vote goes in the git-direction - first step
taken :-) But I hope we'll find a wise decision on how to further
continue in this matter afterwars.
PS: Thank you all for your time and work in this matter.
Regards,
Stefan
If we do decide to make a VCS change the vote should be fairly one
sided for "option of choice" as this has a fairly broad impact on our
development process.Hi Internals,,
after 3 weeks of discussion, I think we are ready to start voting on
the DVCS RFC. If you think something is missing or should be explained
in more detail, let me know.Votes can be found here:
https://wiki.php.net/rfc/dvcs/vote
The RFC can be found here:
Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm.
- David