[RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.

Richard Quadling

15 years ago

On 7 August 2011 21:50, David Soria Parra <dsp@php.net> wrote:

> Hi Internals,
>
> Distributed Version Control Systems (DVCS) getting more and more
> popular. In fact they have been discussed within the PHP community and
> on Internals a few times. It came to my attention that more and more
> people like to see PHP move to a DVCS to solve some of the current
> issues (and get other ones).
>
> I was asked to put together a RFC, and so here we are. I've created
> an initial draft. It is mostly based on the very good Python PEP-0374.
> It compares Git and Mercurial.
>
>    https://wiki.php.net/rfc/dvcs
>
> There are reasons for choosing these systems:
>   * Both are quite popular
>   * I know them
>   * Most PHP devs that I know, know at least on of them
>   * Big projects have recently moved to them, they have
>     similar requirements like PHP
>
> The RFC is far from done, so please help me finishing it and get it out.
>
> This is a call for participation to help to get a (probably heated)
> discussed started and work on the RFC to make it good enough to finally
> choose a system or, and that is a valid option, stay with SVN.
>
> So if:
>  - you are interested in DVCS
>  - know a little bit about PHPs requirements for a DVCS
>  - are not a fanboy
>
> Feel free to discuss this and add your thoughts to the RFC. I would
> love to not do this on my own. Feel free to catch me on IRC (dsp_ on
> php.pecl) and discuss it.
>
> NOTE: this is not the place for any religiouise discussion about git vs
> mercurial whatsover. if you have nothing else to add than "hg is $***
> anyway" or think hosting platform XY will solve all our problems
> without reading the RFC carefully, please post to alt.relgion.* and not
> here.
>
>
> - David

I feel I have a major objection to using a DVCS for PHP.

Currently, a single source provides a sense of authority. If bad code
is committed, it will be quickly dealt with. If good code is
incomplete it may be withdrawn or fixed. In most cases the features
that exist in a branch are well thought out and many clever brains
have seen it and interacted with it to make it what it is.

So, when someone like me comes along, someone capable of building the
code and playing with it at a very minor level, I can be sure that if
things don't work, it is probably me that's broke it and that I can
rely on the branch to contain good working code. OK. I know ITRW,
things do get left unfinished or plain broken. But it isn't as if the
code belongs to a single person who may have not spent all their time
with it.

Whilst I am happy to use my own builds on my dev setups, I'm also
happy to rely on the official releases from The PHP Group.


Now let's envisage a DVCS.

There will be (not might be, but will be), multiple, and potentially
conflicting/incompatible, versions available. Which do I choose? If
everyone is capable of forking PHP, which is the official one? In the
event of a single official repo, then why bother with a DVCS? (I'll
admit I'm naive on the true requirement of DVCS, as I think SVN works
very well).

The main thing I'm worried about is if feature X splits the core devs
so much that there are 2 competing repos, both with a significant
number of core devs supporting each repo, how do I choose which is
which? If my abilities include being able to code at the core level,
which should I support? Both? All 3, 4 or 10 different forks?

Having a single repository for the code makes the code the official,
authoritative version. A DVCS will have too many champions and I feel
would drastically dilute that authority.


Regards,

Richard.

--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

David Soria Parra

15 years ago

On 2011-08-07, Richard Quadling <rquadling@gmail.com> wrote:

> I feel I have a major objection to using a DVCS for PHP.
>
> Currently, a single source provides a sense of authority. If bad code
> is committed, it will be quickly dealt with. If good code is
> incomplete it may be withdrawn or fixed. In most cases the features
> that exist in a branch are well thought out and many clever brains
> have seen it and interacted with it to make it what it is.
>
> So, when someone like me comes along, someone capable of building the
> code and playing with it at a very minor level, I can be sure that if
> things don't work, it is probably me that's broke it and that I can
> rely on the branch to contain good working code. OK. I know ITRW,
> things do get left unfinished or plain broken. But it isn't as if the
> code belongs to a single person who may have not spent all their time
> with it.
>
> Whilst I am happy to use my own builds on my dev setups, I'm also
> happy to rely on the official releases from The PHP Group.
>
>
> Now let's envisage a DVCS.
>
> There will be (not might be, but will be), multiple, and potentially
> conflicting/incompatible, versions available. Which do I choose? If
> everyone is capable of forking PHP, which is the official one? In the
> event of a single official repo, then why bother with a DVCS? (I'll
> admit I'm naive on the true requirement of DVCS, as I think SVN works
> very well).

The objection is valid, but it's just a minor concern. A main repository
in a DVCS is not defined by being the only existant repository, but
rather by common sense and knowledge where to find the main one.

For PHP this is easy: there will be (git|hg).php.net where you will
find the main repository. There is the github.com/php and bitbucket.org/php
user that we own. They will be used to host the main repository.

I think it's very easy to figure out what the main repository is and what not
(particularly as github and bitbucket have fork views where you see
relations and where they've forked from).

So using conventions and common sense tend to work rather well.
An example: it is known that the main linux tree is Linus one, and not
mine, so if you search for the main linux tree you will clone
Linus tree and not mine.

> The main thing I'm worried about is if feature X splits the core devs
> so much that there are 2 competing repos, both with a significant
> number of core devs supporting each repo, how do I choose which is
> which? If my abilities include being able to code at the core level,
> which should I support? Both? All 3, 4 or 10 different forks?
>
> Having a single repository for the code makes the code the official,
> authoritative version. A DVCS will have too many champions and I feel
> would drastically dilute that authority.

I think no Open Source project has yet suffered from what you've described.

-David

Johannes Schlueter

15 years ago

On Sun, 2011-08-07 at 22:13 +0100, Richard Quadling wrote:

> So, when someone like me comes along, someone capable of building the
> code and playing with it at a very minor level, I can be sure that if
> things don't work, it is probably me that's broke it and that I can
> rely on the branch to contain good working code. OK. I know ITRW,
> things do get left unfinished or plain broken. But it isn't as if the
> code belongs to a single person who may have not spent all their time
> with it.

you can fork it as you want on github (you can do that already btw.) but
you won't be able to push it on git.php.net (as you can't do know).

No real difference there.

Only difference is that code can be tracked and manged before reaching
php.net's main tree. There already inofficial versions out there,
sometimes containing "strange" patches. They are called "distribution
packages" - even harder to detect.

johannes

Stas Malyshev

15 years ago

Hi!

On 8/7/11 2:13 PM, Richard Quadling wrote:

> There will be (not might be, but will be), multiple, and potentially
> conflicting/incompatible, versions available. Which do I choose? If
> everyone is capable of forking PHP, which is the official one? In the
> event of a single official repo, then why bother with a DVCS? (I'll
> admit I'm naive on the true requirement of DVCS, as I think SVN works
> very well).

You can build single-source workflows around DCVS too. The fact that
everybody is keeping the copy of the history doesn't mean there can't be
one "main" repository. The point of DCVS is not as much in doing
different things from what we're doing now as doing roughly the same
things in a better way - more efficiently.

> The main thing I'm worried about is if feature X splits the core devs
> so much that there are 2 competing repos, both with a significant
> number of core devs supporting each repo, how do I choose which is
> which? If my abilities include being able to code at the core level,
> which should I support? Both? All 3, 4 or 10 different forks?

This can happen right now - take the code, put it on any of the hosting
facilities and declare yourself the new king of PHP. DCVS changes
nothing here. It's the process that defines the workflows, not the
technology. Technology just makes the workflows easier to execute.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Derick Rethans

15 years ago

On Sun, 7 Aug 2011, Stas Malyshev wrote:

> On 8/7/11 2:13 PM, Richard Quadling wrote:
>
> You can build single-source workflows around DCVS too. The fact that
> everybody is keeping the copy of the history doesn't mean there can't
> be one "main" repository. The point of DCVS is not as much in doing
> different things from what we're doing now as doing roughly the same
> things in a better way - more efficiently.
>
> > The main thing I'm worried about is if feature X splits the core devs
> > so much that there are 2 competing repos, both with a significant
> > number of core devs supporting each repo, how do I choose which is
> > which? If my abilities include being able to code at the core level,
> > which should I support? Both? All 3, 4 or 10 different forks?
>
> This can happen right now - take the code, put it on any of the hosting
> facilities and declare yourself the new king of PHP.

But you can't call it PHP anymore due to the license, where as with a
DCVS with people having forks on publically accessible repositories,
everybody is basically violating the license.

I share Richard's concerns about finding out "what is the real one"/best
one/latest one.

Most recently I found that out with two related PHP projects:

https://github.com/preinheimer/xhprof vs https://github.com/facebook/xhprof

and:
https://github.com/corretge/xdebug-trace-gui or
https://github.com/beberlei/xdebug-trace-gui or
http://www.rdlt.com/xdebug-trace-file-parser.html

regards,
Derick

Adam Harvey

15 years ago

On 12 August 2011 18:26, Derick Rethans <derick@php.net> wrote:

> I share Richard's concerns about finding out "what is the real one"/best
> one/latest one.

I didn't understand the problem when Richard first posted, and I still
don't now, to be honest. The canonical repository is the one the
php.net Web site points to. Surely it's not any harder than that?

Adam

Lester Caine

15 years ago

Adam Harvey wrote:

>> I share Richard's concerns about finding out "what is the real one"/best
>> >  one/latest one.
> I didn't understand the problem when Richard first posted, and I still
> don't now, to be honest. The canonical repository is the one the
> php.net Web site points to. Surely it's not any harder than that?

In theory - yes ... as long as there is an agreed way of pushing/pulling other
peoples changes back into the 'master' copy. It is a matter of 'management' of
who does that process?

The Hg code base is probably a good example of the potential problems ... ( and
git is little better? ) ... You get the CORE software from mercurial, but the
extensions are all over the place, and it's those that make it work for many
people.

PHP has the potential of falling into the same 'trap', since extensions such as
the ones Derick highlights are just the tip of the expansion areas, and while
the core code can be ring fenced, some of the pecl and other extensions could be
managed in third party repos which as highlighted, could potentially be more up
to date than the original code from which it was forked.

Once you have a local copy, doing your own thing, and just pulling in the
changes you like is nice - except you are not running a 'standard' distribution.
I feel there should be a better distinction between 'managing the code' and
building a released distribution? Some projects are using 'clone' as a way to
remove the need to create a stable release, and that I feel is wrong?

--
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

Keloran

15 years ago

all of those you listed, when you look at the fork path, can be traced to
the real root, but thats the point to git, the main might have a bug, and
becasue you can fork, and give pull-requests, until main is fixed, yours
could be counted as the "real" one

On Fri, Aug 12, 2011 at 11:26 AM, Derick Rethans <derick@php.net> wrote:

Ferenc Kovacs

15 years ago

> But you can't call it PHP anymore due to the license, where as with a
> DCVS with people having forks on publically accessible repositories,
> everybody is basically violating the license.
>

you can rename your fork on github:
https://github.com/Tyrael/forphx
usually people don't do this, as they don't want to maintain a
competing project, they only fork it for having their own repo to
develop into until they are done and then send a pull request.

> I share Richard's concerns about finding out "what is the real one"/best
> one/latest one.
>
> Most recently I found that out with two related PHP projects:
>
> https://github.com/preinheimer/xhprof vs https://github.com/facebook/xhprof
>
> and:
> https://github.com/corretge/xdebug-trace-gui or
> https://github.com/beberlei/xdebug-trace-gui or
> http://www.rdlt.com/xdebug-trace-file-parser.html
>

again, see https://github.com/Tyrael/forphx for example:
"Tyrael / forphx
forked from facebook/xhprof"
and you can also use the Network tab on github to see the interactions
between the projects.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Lester Caine

15 years ago

Ferenc Kovacs wrote:

>> But you can't call it PHP anymore due to the license, where as with a
>> >  DCVS with people having forks on publically accessible repositories,
>> >  everybody is basically violating the license.
>> >
> you can rename your fork on github:
> https://github.com/Tyrael/forphx
> usually people don't do this, as they don't want to maintain a
> competing project, they only fork it for having their own repo to
> develop into until they are done and then send a pull request.

Actually the real question here is WHY create a fork on github at all? The copy
you are working on LOCALLY is the fork that you are developing on? Much of the
stuff on github and the other DVCS server sites is redundant? You only need to
publish your local changes to other developers who are working with you not to
the whole world?

Once I realised that the github and bitbucket accounts were part of the problem,
managing the local changes became a lot easier.

--
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

Johannes Schlueter

15 years ago

On Fri, 2011-08-12 at 12:29 +0100, Lester Caine wrote:

> Actually the real question here is WHY create a fork on github at all? The copy
> you are working on LOCALLY is the fork that you are developing on? Much of the
> stuff on github and the other DVCS server sites is redundant? You only need to
> publish your local changes to other developers who are working with you not to
> the whole world?

since i can publish an experimental feature, get it
reviewed/tested/improved before pushing it to the main tree.

Mind that "other developers who are working with you" is potentially
everybody on this list ;-)

johannes

Lester Caine

15 years ago

Johannes Schlüter wrote:

>> Actually the real question here is WHY create a fork on github at all? The copy
>> >  you are working on LOCALLY is the fork that you are developing on? Much of the
>> >  stuff on github and the other DVCS server sites is redundant? You only need to
>> >  publish your local changes to other developers who are working with you not to
>> >  the whole world?
> since i can publish an experimental feature, get it
> reviewed/tested/improved before pushing it to the main tree.
>
> Mind that "other developers who are working with you" is potentially
> everybody on this list;-)

But that is the point ... if everybody has their own published 'experimental
feature' repos, syncing those bits we are playing with looks like a nightmare?
Surly the point of DVCS is we share via some central pot, and these experimental
branches exist there? Having to keep track of who's bits you are playing with is
the messy bit :( And it's that which has caused problems with other projects,
where 'extensions' have grown in secondary repos ... and become the official
extension. That is what I think people are just trying to flag up.

--
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

Nathaniel Catchpole

15 years ago

fwiw with Drupal we have a central repository for the core and contributed
projects hosted on Drupal.org. There are also sandbox projects (which can be
either experimental new projects or forks), and these are also centrally
hosted.

This doesn't stop people using github, but it massively increased commit
activity on Drupal.org after the switch from cvs (when a lot of people had
moved active development to github due to not liking cvs, and definitely
some people have come back since).

Nathaniel

On Fri, Aug 12, 2011 at 9:14 PM, Lester Caine <lester@lsces.co.uk> wrote:

Stas Malyshev

15 years ago

Hi!

On 8/12/11 5:14 AM, Lester Caine wrote:

> But that is the point ... if everybody has their own published 'experimental
> feature' repos, syncing those bits we are playing with looks like a nightmare?

Of course. Unless you are using modern tools to manage this, like, hmmm,
github? ;)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Matthew Weier O'Phinney

15 years ago

On 2011-08-12, Lester Caine <lester@lsces.co.uk> wrote:

> Johannes Schlüter wrote:
> > > > Actually the real question here is WHY create a fork on github
> > > > at all? The copy you are working on LOCALLY is the fork that you
> > > > are developing on? Much of the stuff on github and the other
> > > > DVCS server sites is redundant? You only need to publish your
> > > > local changes to other developers who are working with you not
> > > > to the whole world?
> > since i can publish an experimental feature, get it
> > reviewed/tested/improved before pushing it to the main tree.
> >
> > Mind that "other developers who are working with you" is potentially
> > everybody on this list;-)
>
> But that is the point ... if everybody has their own published
> 'experimental feature' repos, syncing those bits we are playing with
> looks like a nightmare?  Surly the point of DVCS is we share via some
> central pot, and these experimental branches exist there? Having to
> keep track of who's bits you are playing with is the messy bit :( And
> it's that which has caused problems with other projects, where
> 'extensions' have grown in secondary repos ... and become the official
> extension. That is what I think people are just trying to flag up.

Actually, it's not a nightmare; it's incredibly easy, and actually helps
keep features and bugfixes more sandboxed, and thus more easily reviewed
and merged.

As an example, let's say I as a developer want to develop feature Y for
the language. I create a new branch locally, and start developing. As I
near a point where it seems ready, I rebase from the canonical
repository, and check to see if any conflicts occur between my code and
what's come in on the main repo. If all looks good, I ask for review,
and, after a few rounds of back and forth and some coding, again rebase,
and then ask for somebody to merge. The nice part about this is it puts
the onus on the individual developers to ensure they have clean patches
-- if a merge request doesn't apply cleanly, you throw it back and ask
them to submit again when it does.

Now, let's say while I'm working on feature Y, I also tackle issues X,
Z, and A. I do each of these in their own hotfix branches. The nice part
is that there's easy, simple segregation between each fix, and I can
move back and forth between the branches quickly and with no bleed-over.

When it comes to the central repo, you have somebody or a team of people
basically reviewing, merging, and pushing in pull requests. A release
master is "king" or "queen" of a particular release branch, and is the
one who decides if/when a feature is merged to that branch.

The main thing is making it clear who is responsible for merging into a
"master" branch, and who is responsible for merging into a release
branch -- in other words, it comes down to processes. And, frankly, the
processes are not terribly unlike the status quo -- the real question is
what version control system is the best fit for that process. DVCS tools
are (generally) optimized for quick branching, ease of merging, and
minimizing commit size -- all of which could potentially benefit PHP
development.

--
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Stas Malyshev

15 years ago

Hi!

On 8/12/11 4:29 AM, Lester Caine wrote:

> Actually the real question here is WHY create a fork on github at all? The copy

Pull requests, for one.

> you are working on LOCALLY is the fork that you are developing on? Much of the
> stuff on github and the other DVCS server sites is redundant? You only need to

I think you confusing "not absolutely required" and "redundant" :) Of
course you could do without any infrastructure github provides. But it
makes life so much easier. Especially when you are working in a team
bigger than 1 person.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Lester Caine

15 years ago

Stas Malyshev wrote:

>> Actually the real question here is WHY create a fork on github at all?
>> The copy
> Pull requests, for one.

Push/Pull from local copy?
My point was that many of the forks currently ON github are simply not required?

>> you are working on LOCALLY is the fork that you are developing on?
>> Much of the
>> stuff on github and the other DVCS server sites is redundant? You only
>> need to
>
> I think you confusing "not absolutely required" and "redundant" :) Of
> course you could do without any infrastructure github provides. But it
> makes life so much easier. Especially when you are working in a team
> bigger than 1 person.

The TEAM has a master copy on github or better still git.php.net, but you don't
need 10000 other copies on github as well? I don't like the code Drupal produce,
but the framework for code management is only let down by being git based :)
Sandboxes and development branches are the right way to go, but could actually
be provided in a DVCS agnostic way on a php.net framework? hg.php.net +
git.php.net in parallel ... with the existing packaged distributions for those
who do not need code access?

--
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

Stas Malyshev

15 years ago

Hi!

On 8/12/11 11:47 AM, Lester Caine wrote:

>> Pull requests, for one.
> Push/Pull from local copy?

No, no. Pull requests and push/pull are very different things. Having
people just push whatever they like whenever they like into main code is
what we have now, and it's not really the best way to work on a big
project. Please see on github how pull requests are implemented.

> The TEAM has a master copy on github or better still git.php.net, but you don't
> need 10000 other copies on github as well? I don't like the code Drupal produce,

It's not copies. And yes, I need them - because not every change should
immediately go into master repo. Much better way is to publish it in
your local repo and have it reviewed and then merged into master repo.
Or not. Or merged later. github allows to manage this process better
than storing assorted patches in emails and bugs and pastebin, etc.

> Sandboxes and development branches are the right way to go, but could actually

Branches are different things than github forks, for different purposes.
Branch is a project, fork is a workspace. You can have multiple people
work on a project, using multiple workspaces.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Justin Rovang

15 years ago

GitHub (and Bitbucket) have made forking a social endeavour - it's meant
to be a noisy space of code forks for collaboration just as Stas mentioned.

Bottom line: *if* a DVCS is adopted - enhancing policies and a process
that supports little additional burden on maintainers is required.
Having those in place would seem to address the most prudent fear in
this conversation.

Just because somebody uses DVCS / Github / Bitbucket; doesn't entitle
them to anything more than before. It's just another means to
collaborate in a more rapid manner; with updated tooling.

On 8/12/2011 2:02 PM, Stas Malyshev wrote:

Richard Quadling

15 years ago

On 12 August 2011 20:02, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Branches are different things than github forks, for different purposes.
> Branch is a project, fork is a workspace. You can have multiple people work
> on a project, using multiple workspaces.

And today I learned something.

--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

Lester Caine

15 years ago

Stas Malyshev wrote:

>> Sandboxes and development branches are the right way to go, but could
>> actually
>
> Branches are different things than github forks, for different purposes.
> Branch is a project, fork is a workspace. You can have multiple people
> work on a project, using multiple workspaces.

That is not how Drupal seems to be using git ...
http://drupal.org/node/803746#clone - See 'Creating a Working Branch'

Personally that is not how I'd like to see php going ... but I'm more than happy
with my own hg workspace locally anyway :)

--
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

Matthew Weier O'Phinney

15 years ago

On 2011-08-12, Lester Caine <lester@lsces.co.uk> wrote:

> Ferenc Kovacs wrote:
> > > But you can't call it PHP anymore due to the license, where as with a
> > > >  DCVS with people having forks on publically accessible repositories,
> > > >  everybody is basically violating the license.
> > > >
> > you can rename your fork on github:
> > https://github.com/Tyrael/forphx
> > usually people don't do this, as they don't want to maintain a
> > competing project, they only fork it for having their own repo to
> > develop into until they are done and then send a pull request.
>
> Actually the real question here is WHY create a fork on github at all?
> The copy you are working on LOCALLY is the fork that you are
> developing on? Much of the stuff on github and the other DVCS server
> sites is redundant? You only need to publish your local changes to
> other developers who are working with you not to the whole world?

And how do you publish those changes? How do you get review? Yes, you
can send patches, but it's often easier to point a person to a
repository and branch, and let the reviewer -- or reviewers -- decide
how to review -- a diff between the canonical repo and the change
branch, using a web-based review system such as GitHub offers, etc. The
web-based tools GitHub and BitBucket should not be discounted -- having
the ability to have comment-threads per line of code is very useful for
keeping the review targetted as well as easily identifying code that may
need tuning.

--
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Johannes Schlueter

15 years ago

On Fri, 2011-08-12 at 11:26 +0100, Derick Rethans wrote:

> But you can't call it PHP anymore due to the license, where as with a
> DCVS with people having forks on publically accessible repositories,
> everybody is basically violating the license.

If this kind of a "fork" makes it a "product" as the license has
restrictions only about "products" called PHP or which are being
endorsed/promoted as such only. One can certainly argue that a source
"fork" on such a site makes no new independent product.

Besides that I assume that The PHP Group will handle this, if needed,
after such a move.

johannes

Sebastian Bergmann

15 years ago

On 08/12/2011 06:26 AM, Derick Rethans wrote:

> I share Richard's concerns about finding out "what is the real one"/best
> one/latest one.

I do not think of the network of clones of PHPUnit's Git repository
(https://github.com/sebastianbergmann/phpunit/network/members) as forks.
It's merely GitHub's name for a project on their site that has a clone
of another project's Git repository.

I do not think that we would run a risk of people not knowing where the
official/canonical Git repository for PHP can be found.

--
Sebastian Bergmann                    Co-Founder and Principal Consultant
http://sebastian-bergmann.de/                           http://thePHP.cc/

Sean Coates

15 years ago

> https://github.com/preinheimer/xhprof vs https://github.com/facebook/xhprof

IMO, this is actually a good example of how it's *beneficial* to have diverging trees (forks).

Paul's xhprof is (or at least /was/; I believe it still is, but I haven't looked at the facebook tree in a long time) FAR ahead of Facebook's "official" tree, and as far as the UI is concerned, I'd recommend it over the official tree every time.

Food for thought, only. (-:

S

Stas Malyshev

15 years ago

Hi!

On 8/12/11 3:26 AM, Derick Rethans wrote:

> But you can't call it PHP anymore due to the license, where as with a
> DCVS with people having forks on publically accessible repositories,
> everybody is basically violating the license.

Well, the license is something to think about, yes.

>
> I share Richard's concerns about finding out "what is the real one"/best
> one/latest one.

This however I don't see how it's a concern. How hard it is to remember
git.php.net? How hard it is to know PHP's git repository is the main
one? How it's different from what we have now?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Stas Malyshev

15 years ago

Hi!

As somebody that have seen reasonably big project switch from SVN to git
and worked quite actively with git since then, I think describing my
experience might be useful for those that never tried it.

1. git is much better than svn especially as applied to complex projects
with multiple participants which need to accept outside patches,
maintain multiple branches and port fixes between branches. You never
know how much you needed cheap branching/merging until you worked with
it some.

2. Switching from svn to git requires one to undergo some mental shift,
and for the first couple of weeks you may be confused and somewhat
frustrated by too many things that look like but not exactly like the
old system. It would appear too complex and unnecessarily complicating
workflows. However, as you develop new routines, you'll find out how it
makes sense and will become more effective than with svn. Note that git
IS much more complex conceptually than SVN and allows to do much more
crazy things - including rewriting history in all kinds of weird ways -
so while I don't think I had to ask SVN question in forums for years - I
still have to google "how to do this in git" and ask around for some of
the more complex things. I think it's still worth it. Don't know if it
makes me a fanboy :)

3. Having system like github around it adds a lot - maintaining multiple
repositories, forks and pull requests is a real boon. I'm not sure if it
would make sense for php, all things considered, but there are very
significant benefits of using such a system where many workflows are
already built-in.


Please note that it's not "hg vs git" argument as I know very little
about hg and have no experience working with it, but I've read what
people write about it and I'm sure many of git's strengths are present
in hg too. I hope somebody with experience in hg (or both, even better)
will voice in.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

David Soria Parra

15 years ago

On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
> As somebody that have seen reasonably big project switch from SVN to git
> and worked quite actively with git since then, I think describing my
> experience might be useful for those that never tried it.
>
> 1. git is much better than svn especially as applied to complex projects
> with multiple participants which need to accept outside patches,
> maintain multiple branches and port fixes between branches. You never
> know how much you needed cheap branching/merging until you worked with
> it some.
>
> 2. Switching from svn to git requires one to undergo some mental shift,
> and for the first couple of weeks you may be confused and somewhat
> frustrated by too many things that look like but not exactly like the
> old system. It would appear too complex and unnecessarily complicating
> workflows. However, as you develop new routines, you'll find out how it
> makes sense and will become more effective than with svn. Note that git
> IS much more complex conceptually than SVN and allows to do much more
> crazy things - including rewriting history in all kinds of weird ways -
> so while I don't think I had to ask SVN question in forums for years - I
> still have to google "how to do this in git" and ask around for some of
> the more complex things. I think it's still worth it. Don't know if it
> makes me a fanboy :)
>
> 3. Having system like github around it adds a lot - maintaining multiple
> repositories, forks and pull requests is a real boon. I'm not sure if it
> would make sense for php, all things considered, but there are very
> significant benefits of using such a system where many workflows are
> already built-in.

having a dvcs will enable us to use pull requests in github. (maybe
you will not able to use the big merge button but rather do it yourself,
but still it's a huge improvement).

>
>
> Please note that it's not "hg vs git" argument as I know very little
> about hg and have no experience working with it, but I've read what
> people write about it and I'm sure many of git's strengths are present
> in hg too. I hope somebody with experience in hg (or both, even better)
> will voice in.

yes hg offers most of this too. your arguments are general arguments in
favor of DVCS. There are some minor differences in branching and file
handling so some people call hg easier to learn when coming from SVN.
Particularly branching is different in hg as outlined in the RFC,
making pure lightweight branches a little bit more difficult to handle
than in git, but allowing non-lightweight branches which don't exist in
Git (this mean that you can forever tell on which branch a changeset
was comitted)

Richard Riley

15 years ago

David Soria Parra <dsp@php.net> writes:

> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> Hi!
>>
>> As somebody that have seen reasonably big project switch from SVN to git
>> and worked quite actively with git since then, I think describing my
>> experience might be useful for those that never tried it.
>>
>> 1. git is much better than svn especially as applied to complex projects
>> with multiple participants which need to accept outside patches,
>> maintain multiple branches and port fixes between branches. You never
>> know how much you needed cheap branching/merging until you worked with
>> it some.
>>
>> 2. Switching from svn to git requires one to undergo some mental shift,
>> and for the first couple of weeks you may be confused and somewhat
>> frustrated by too many things that look like but not exactly like the
>> old system. It would appear too complex and unnecessarily complicating
>> workflows. However, as you develop new routines, you'll find out how it
>> makes sense and will become more effective than with svn. Note that git
>> IS much more complex conceptually than SVN and allows to do much more
>> crazy things - including rewriting history in all kinds of weird ways -
>> so while I don't think I had to ask SVN question in forums for years - I
>> still have to google "how to do this in git" and ask around for some of
>> the more complex things. I think it's still worth it. Don't know if it
>> makes me a fanboy :)
>>
>> 3. Having system like github around it adds a lot - maintaining multiple
>> repositories, forks and pull requests is a real boon. I'm not sure if it
>> would make sense for php, all things considered, but there are very
>> significant benefits of using such a system where many workflows are
>> already built-in.
> having a dvcs will enable us to use pull requests in github. (maybe
> you will not able to use the big merge button but rather do it yourself,
> but still it's a huge improvement).

Its really simple.

Use git.

It works, is fast and is rapidly becoming the industry standard. Do not
sue something for "moral grounds" like the awful bzr used for emacs.

Its designed as a fast, efficient DVCS.

Stefan Neufeind

15 years ago

On 08/07/2011 11:37 PM, Richard Riley wrote:

> David Soria Parra <dsp@php.net> writes:
>
>> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

[...]

> Its really simple.
>
> Use git.
>
> It works, is fast and is rapidly becoming the industry standard. Do not
> sue something for "moral grounds" like the awful bzr used for emacs.
>
> Its designed as a fast, efficient DVCS.

Hi,

The TYPO3-folks migrated to git some while ago. And lately their
review-system "review.typo3.org" (readonly now also without a login)
went live. The review-system itself is actually another git in front
where changes for review can be pushed, can be reviewed, changed and be
mangled around, can be finally be abandoned or merged. At merge it's
pushed into the main repo. That was a huge win in terms of formal
reviews, transparency, speed and ease of reviews etc. And it even helped
bug-tracking since now there are no few lines of code hidden in the
bugtracker as some kind of "patch" or "quickfix" but that is actually a
git-change that you can checkout from review.typo3.org using your git
(the system tells you which commandline to use for that). Imho it's
dead-simple.

I believe it would help PHP a lot to have this kind of transparency and
increase both the quality as well as the speed/ease of reviews.


Regards,
Stefan

Ferenc Kovacs

15 years ago

On Mon, Aug 8, 2011 at 1:35 AM, Stefan Neufeind <neufeind@php.net> wrote:

> On 08/07/2011 11:37 PM, Richard Riley wrote:
>> David Soria Parra <dsp@php.net> writes:
>>
>>> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>
> [...]
>
>> Its really simple.
>>
>> Use git.
>>
>> It works, is fast and is rapidly becoming the industry standard. Do not
>> sue something for "moral grounds" like the awful bzr used for emacs.
>>
>> Its designed as a fast, efficient DVCS.
>
> Hi,
>
> The TYPO3-folks migrated to git some while ago. And lately their
> review-system "review.typo3.org" (readonly now also without a login)
> went live. The review-system itself is actually another git in front
> where changes for review can be pushed, can be reviewed, changed and be
> mangled around, can be finally be abandoned or merged. At merge it's
> pushed into the main repo. That was a huge win in terms of formal
> reviews, transparency, speed and ease of reviews etc. And it even helped
> bug-tracking since now there are no few lines of code hidden in the
> bugtracker as some kind of "patch" or "quickfix" but that is actually a
> git-change that you can checkout from review.typo3.org using your git
> (the system tells you which commandline to use for that). Imho it's
> dead-simple.
>
> I believe it would help PHP a lot to have this kind of transparency and
> increase both the quality as well as the speed/ease of reviews.
>
>
> Regards,
>  Stefan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

btw. for code-review and change control there are also existing open
source tools like gerrit for git.
http://code.google.com/p/gerrit/

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Kiall Mac Innes

15 years ago

Yes - Gerrit is what Typo3, CyanogenMod, OpenStack and of course, Android
are using...

The OpenStack guys have a good introduction on how to use Gerrit from a
developers point of view - http://wiki.openstack.org/GerritWorkflow

The CyanogenMod guys have a good introduction on how to use Gerrit AND Repo
(a multiple repository management tool) from a developers point of view -
http://wiki.cyanogenmod.com/wiki/Howto:_Gerrit

Also - There is a Gerrit plugin for the Jenkins CI server that allows for
pre-testing commits if desired -
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Plugin

Thanks,
Kiall


On Mon, Aug 8, 2011 at 12:44 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

Stefan Neufeind

15 years ago

On 08/08/2011 01:44 AM, Ferenc Kovacs wrote:

> On Mon, Aug 8, 2011 at 1:35 AM, Stefan Neufeind <neufeind@php.net> wrote:
>> On 08/07/2011 11:37 PM, Richard Riley wrote:
>>> David Soria Parra <dsp@php.net> writes:
>>>
>>>> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>>
>> [...]
>>
>>> Its really simple.
>>>
>>> Use git.
>>>
>>> It works, is fast and is rapidly becoming the industry standard. Do not
>>> sue something for "moral grounds" like the awful bzr used for emacs.
>>>
>>> Its designed as a fast, efficient DVCS.
>>
>> Hi,
>>
>> The TYPO3-folks migrated to git some while ago. And lately their
>> review-system "review.typo3.org" (readonly now also without a login)
>> went live. The review-system itself is actually another git in front
>> where changes for review can be pushed, can be reviewed, changed and be
>> mangled around, can be finally be abandoned or merged. At merge it's
>> pushed into the main repo. That was a huge win in terms of formal
>> reviews, transparency, speed and ease of reviews etc. And it even helped
>> bug-tracking since now there are no few lines of code hidden in the
>> bugtracker as some kind of "patch" or "quickfix" but that is actually a
>> git-change that you can checkout from review.typo3.org using your git
>> (the system tells you which commandline to use for that). Imho it's
>> dead-simple.
>>
>> I believe it would help PHP a lot to have this kind of transparency and
>> increase both the quality as well as the speed/ease of reviews.
>
> btw. for code-review and change control there are also existing open
> source tools like gerrit for git.
> http://code.google.com/p/gerrit/

They use gerrit. It's just configured with a few nice hooks like to
automatically update a ticket-status when a new patch is sent to the
review-system or when it is merged (issue referenced by "Resolves:
#xxxxx" in the comment is closed). Also a build-bot is triggered which
sends its results for each patchset into the review and things like that.


Regards,
Stefan

Hannes Landeholm

15 years ago

Hi,

I'd +1 moving to git. I just moved my own project to github from our own
SVN. Mainly for economical reasons as this allowed us to not have to
maintain our own repository and because github had excellent features.
Another point was of course git's superiority over svn when it comes to many
basic features such as keeping your own local repository, branching, tagging
etc.

I'd also recommend that you see this insightful and hilarious talk by Linus
Torvalds if you haven't already:

http://www.youtube.com/watch?v=4XpnKHJAok8

~Hannes

Lester Caine

15 years ago

Richard Riley wrote:

> Its really simple.
>
> Use git.

And stick two fingers up at the windows developer base ;)

> It works, is fast and is rapidly becoming the industry standard. Do not
> sue something for "moral grounds" like the awful bzr used for emacs.

Mercurial is just as popular, especially if you want to support windows projects
in parallel with Linux ones ...
TortoiseHg just works on both windows and Linux, integrates nicely into file
managment and plays nicely in Eclipse ... TortoiseGit is windows only and has
compatibility problems.

> Its designed as a fast, efficient DVCS.

Ditto ...

But it does not matter two hoots which one you go for ...
http://lsces.co.uk/hg/
we can quite happily use either locally. All that needs to be agreed on is HOW a
master distribution clone is managed. Managing transfers of patches between
sites requires a lot more management which SVN simply provides by default.
Keeping the 'master' as SVN may not be such a bad thing as long as git/hg
mirrors also exist.

I've been through many hoops over the last year since git was forced on me by
other projects ... git needs to start playing better with windows users, as it's
current offering does NOT work on sites where other SSH activities are already
installed. WHile hg just worked out of the box.

The current problem is that neither play well together in the area of sub-repos
and this is an area that is still very much work in progress? Manually cloning
each individual element does currently work though, and that is how I'm
currently remaining sane ...

--
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

Stas Malyshev

15 years ago

Hi!

On 8/7/11 5:46 PM, Lester Caine wrote:

>> Use git.
> And stick two fingers up at the windows developer base ;)

What's the problem with git and windows? I understand there is a good
GUI-installable package with all needed and everything works just fine -
at least I know people using it without any trouble.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Lester Caine

15 years ago

Stas Malyshev wrote:

> On 8/7/11 5:46 PM, Lester Caine wrote:
>>> Use git.
>> And stick two fingers up at the windows developer base ;)
>
> What's the problem with git and windows? I understand there is a good
> GUI-installable package with all needed and everything works just fine -
> at least I know people using it without any trouble.

Things have improved somewhat over the last year ... A year ago even the git
people would admit that they did not do windows well ...

Having to deal with many sites that are 'windows only', but now supplying them
Linux boxes with FLAP installations, we make them 'look' like windows boxes for
the IT department, so WinSCP and Putty are the order of the day. I've not tried
again in the last few months, but last time I installed the msysgit, parts of my
SSH process stopped working! If one has a working cygwin install then it should
be possible to run it on that, but it appears now that it may have been that
which caused some of my own problems since there was a cygwin installation as well.

TortoiseGit prefers msysgit installed but it can now be installed using the
existing putty installation now. But it is still a windows only option, while
the TortoiseHg package works transparently on both. I'll put my hand up that it
clashes with Powerdesk on Windows, but I've been lucky up to now that Powerdesk
worked at all, and M$ HAS now provided most of its facilities now anyway, and I
tend to work from a Linux box anyway so don't really need it.

Another method of working cross platform is Eclipse ... Jgit/Egit are making
progress, but do not currently support the git subrepo. The hg plugin still has
a few problems but on the whole it is now usable, although I do still prefer
TortoiseHg via Nautilus for managing updates.

I'm not sure on the current situation with git, but Hg does transparently
connect with git, which is how I have been working for a long time now. I've
moved my own CVS archives over to Hg, and manage the SVN repo's via it as well.
SO at the end of the day I'm not that bothered if the consensus is Git. I'm just
laying out all the reasons why I never got on with it, many of which still
currently apply. I've been using a package called BeyondCompare since long
before it was ported to Linux, and this integrates seamlessly into Eclipse and
TortoiseHg on both platforms ( and I understand Mac ).

Kiall

> Re: Windows Only - I'm yet to meet a Linux developer who prefers a git GUI over the git CLI ;)

That I think sums up the problem with much of the Linux development process? For
years I have been using Eclipse for all my software development. On CVS and SVN
archives I can SEE a list of the files that have changes, compare things that I
am working on, select what I apply to my local copy. Currently neither git nor
hg provide the same level of control, I have to run a separate clone of the
'master' and run BC to view the same details. I know I am in a minority and
probably a dinosaur, but I've wasted months trying to get back to a level of
productivity that I had last year, and yet still have on projects that have not
moved to DVCS!

Personally I expect a conversion to DVCS would create more sustainable forks of
PHP, perhaps we can maintain our own personal builds ignoring some of the
'unnecessary' stuff added since 5.2 :) This is exactly what is happening on
other projects, since one can pull what you want and branch on what you don't.
There are no restrictions which is why the management process becomes more
important!

( CRLF -> LF conversion is never a problem - just don't use notepad in windows :) )

--
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

Kiall Mac Innes

15 years ago

On Mon, Aug 8, 2011 at 1:46 AM, Lester Caine <lester@lsces.co.uk> wrote:

> Richard Riley wrote:
>
>> Its really simple.
>>
>> Use git.
>>
> And stick two fingers up at the windows developer base ;)

I admit I don't use windows often, but when I do, TortoiseGit has always
worked fine for me!

>  It works, is fast and is rapidly becoming the industry standard. Do not
>> sue something for "moral grounds" like the awful bzr used for emacs.
>>
> Mercurial is just as popular, especially if you want to support windows
> projects in parallel with Linux ones ...
> TortoiseHg just works on both windows and Linux, integrates nicely into
> file managment and plays nicely in Eclipse ... TortoiseGit is windows only
> and has compatibility problems.
>
>

Compatibility problems? I assume you mean CRLF -> LF conversion? CRLF -> LF
conversion (IIRC) is on by default, unless you choose otherwise during
installation.

Re: Windows Only - I'm yet to meet a Linux developer who prefers a git GUI
over the git CLI ;)

Thanks,
Kiall

Ryan McCue

15 years ago

Lester Caine wrote:

> Richard Riley wrote:
>> Its really simple.
>>
>> Use git.
> And stick two fingers up at the windows developer base ;)

The CLI works exactly the same as on any other platform, and the
graphical tools are fairly good. I've found that they're at least as
good as Hg's Windows tools.

FWIW, I manage a whole bunch of projects on Git from Windows and I've
never had an issue.

(Forgot to send this to the list, again.)

--
Ryan McCue
<http://ryanmccue.info/>

David Muir

15 years ago

On 08/08/11 07:37, Richard Riley wrote:

> David Soria Parra <dsp@php.net> writes:
>
>> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>>> Hi!
>>>
>>> As somebody that have seen reasonably big project switch from SVN to git
>>> and worked quite actively with git since then, I think describing my
>>> experience might be useful for those that never tried it.
>>>
>>> 1. git is much better than svn especially as applied to complex projects
>>> with multiple participants which need to accept outside patches,
>>> maintain multiple branches and port fixes between branches. You never
>>> know how much you needed cheap branching/merging until you worked with
>>> it some.
>>>
>>> 2. Switching from svn to git requires one to undergo some mental shift,
>>> and for the first couple of weeks you may be confused and somewhat
>>> frustrated by too many things that look like but not exactly like the
>>> old system. It would appear too complex and unnecessarily complicating
>>> workflows. However, as you develop new routines, you'll find out how it
>>> makes sense and will become more effective than with svn. Note that git
>>> IS much more complex conceptually than SVN and allows to do much more
>>> crazy things - including rewriting history in all kinds of weird ways -
>>> so while I don't think I had to ask SVN question in forums for years - I
>>> still have to google "how to do this in git" and ask around for some of
>>> the more complex things. I think it's still worth it. Don't know if it
>>> makes me a fanboy :)
>>>
>>> 3. Having system like github around it adds a lot - maintaining multiple
>>> repositories, forks and pull requests is a real boon. I'm not sure if it
>>> would make sense for php, all things considered, but there are very
>>> significant benefits of using such a system where many workflows are
>>> already built-in.
>> having a dvcs will enable us to use pull requests in github. (maybe
>> you will not able to use the big merge button but rather do it yourself,
>> but still it's a huge improvement).
>
> Its really simple.
>
> Use git.
>
> It works, is fast and is rapidly becoming the industry standard. Do not
> sue something for "moral grounds" like the awful bzr used for emacs.
>
> Its designed as a fast, efficient DVCS.
>

It's not bzr's fault that someone had the bright idea of setting up the
server to serve the emacs' repo via a slow "dumb" protocol (sftp).

I've been using mercurial for the past 2 months and Bazaar for the past
4 years. My personal preference is Bazaar as it handles my workflow much
better than Mercurial does. Mercurial seems to encourage a "commit
everything to trunk in a linear fashion" like svn. Named branches seem
to be the only way to ensure that a merge comes in as a single commit
rather than a "fast-forward merge", but they're discouraged for some odd
reason. Maybe there are some extensions that make mercurial easier to
use in this regard, but I haven't looked too hard. Maybe that's not a
big problem for some projects, but for me, I like to know when a
particular feature was landed in trunk, and what commits are related to
it, so when I revert a change, I'm only reverting a single commit rather
than having to weed through the tree to find all the commits that need
to be reversed. And if I'm "doing it wrong™", please let me know off
list how I can improve things.

I have not used git yet, so I can't comment much there other than that
the impression I get is that it's probably the most capable system out
there, but where it still has a ways to go is usability. I hear that's
getting better too, but this git-cheatsheet
(http://www.ndpsoftware.com/git-cheatsheet.html) still confuses me.

John Szakmeister, who is a Subversion developer himself, has a good
comparison of svn, hg, bzr and git:
http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/

Long story short, his company went with git.

Cheers,
David

Lester Caine

15 years ago

David Muir wrote:

> I'm only reverting a single commit rather
> than having to weed through the tree to find all the commits that need
> to be reversed. And if I'm "doing it wrong™", please let me know off
> list how I can improve things.

I think this a general problem with DVCS method of working? At least hg and git
... undoing a single file within a changeset is not the easiest thing to do. You
end up comitting the chnaged file back in again? So either you make more commits
so that change sets are smaller, or you start running parallel branches.

--
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

15 years ago

David Muir wrote:

> John Szakmeister, who is a Subversion developer himself, has a good
> comparison of svn, hg, bzr and git:
> http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/
>
> Long story short, his company went with git.

Makes good reading ... many other comparisons are now getting long in the tooth,
and so don't cover the current playing field. Still it looks like 'best of a bad
job' rather than 'this wins hands down' and does make a fair comparison of all
the current problems, but I think the fact that he has not investigated
submodules may actually negate their final results :( This was the main area
that I needed to work well, but is still work in progress everywhere?

--
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

15 years ago

On 09/08/11 01:07, Lester Caine wrote:

> David Muir wrote:
>> John Szakmeister, who is a Subversion developer himself, has a good
>> comparison of svn, hg, bzr and git:
>> http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/
>>
>>
>> Long story short, his company went with git.
>
> Makes good reading ... many other comparisons are now getting long in
> the tooth, and so don't cover the current playing field. Still it
> looks like 'best of a bad job' rather than 'this wins hands down' and
> does make a fair comparison of all the current problems, but I think
> the fact that he has not investigated submodules may actually negate
> their final results :( This was the main area that I needed to work
> well, but is still work in progress everywhere?
>

He did mention submodules as a Pro for git, but you're right, he didn't
compare it with Hg's subrepos and subhg and Bzr's nested trees,
bzr-externals and scmproj. I have a feeling that git's native support
for it is much more mature than the others. That said, it's not a
feature I've looked into myself as it's not something I've actually needed.

Cheers,
David

dukeofgaming

15 years ago

Hi, very glad this topic has resurfaced and I honesly think using a DVCS
will be a game-changer for PHP. Just wanted to drop a couple of answers I've
dedicated some time in at SE, several diagrams, to-point explanations and
references that might be of uso to clear out introductory topics.

http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080
http://programmers.stackexchange.com/questions/77475/how-to-choose-between-git-and-mercurial/77663#77663
http://programmers.stackexchange.com/questions/31558/version-control-for-small-team/31564#31564

In brief: either git or mercurial will be a great option, but if the
majority of the dev-base has less experience with DVCS, there might be more
frustration if you get introduced to DVCS with git than with mercurial, same
goes for potential collaborators, so mercurial —IMHO— does lower the barrier
of entry.

Lots of people choose git over mercurial over github, but bitbucket is
improving more frequently under Atlassian's watch.

Since the project is big enough, git might be a better choice
to accommodate PHP's most complex code workflows —which I'm totally
unfamiliar with—. Mercurial, OTOH, has less power tools to play with than
with wgit, but unless you really really need them, my take on this is: go
with mercurial and lower the collaboration barrier as much as you can.

Best regards,

David

On Mon, Aug 8, 2011 at 8:01 PM, David Muir <davidkmuir@gmail.com> wrote:

Larry Garfield

15 years ago

On 08/07/2011 04:24 PM, Stas Malyshev wrote:

> Hi!
>
> As somebody that have seen reasonably big project switch from SVN to
> git and worked quite actively with git since then, I think describing
> my experience might be useful for those that never tried it.
>
> 1. git is much better than svn especially as applied to complex
> projects with multiple participants which need to accept outside
> patches, maintain multiple branches and port fixes between branches.
> You never know how much you needed cheap branching/merging until you
> worked with it some.
>
> 2. Switching from svn to git requires one to undergo some mental
> shift, and for the first couple of weeks you may be confused and
> somewhat frustrated by too many things that look like but not exactly
> like the old system. It would appear too complex and unnecessarily
> complicating workflows. However, as you develop new routines, you'll
> find out how it makes sense and will become more effective than with
> svn. Note that git IS much more complex conceptually than SVN and
> allows to do much more crazy things - including rewriting history in
> all kinds of weird ways - so while I don't think I had to ask SVN
> question in forums for years - I still have to google "how to do this
> in git" and ask around for some of the more complex things. I think
> it's still worth it. Don't know if it makes me a fanboy :)
>
> 3. Having system like github around it adds a lot - maintaining
> multiple repositories, forks and pull requests is a real boon. I'm not
> sure if it would make sense for php, all things considered, but there
> are very significant benefits of using such a system where many
> workflows are already built-in.
>
>
> Please note that it's not "hg vs git" argument as I know very little
> about hg and have no experience working with it, but I've read what
> people write about it and I'm sure many of git's strengths are present
> in hg too. I hope somebody with experience in hg (or both, even
> better) will voice in.

Drupal completed a move from CVS to Git earlier this year, and our
experience was similar.  There is a mental shift from a centralized VCS
to Git, and that is not a small one, but once it's made there is simply
no going back.  Pretty much everyone agrees that moving to Git was one
of the best things we've done in a long time, and not just because we
all hated CVS. :-)

A previous poster claimed that a DVCS would lead to confusion as to what
the canonical repository was.  That is, in my experience, a common fear
of someone who has not used a DVCS in production.  I know, I used to
have the same concern about Git before I actually got to use it.  Once I
got my hands dirty with it, however, I understood what everyone was so
excited about.  Git is such an amazingly more productive way to work,
the documentation is superb, and the workflow so much saner.  It's the
first VCS I've used where I actually "get" what is going on internally.

A DVCS, properly managed, does not encourage confusion over forks.  If
anything, if properly used it makes it easier for forks to come back
into the fold later if all parties agree to do so.  It's really all a win.

Our Windows-based developers also have not really had an issue. :-)

--Larry Garfield

Ronald Chmara

15 years ago

On Mon, Aug 8, 2011 at 6:52 PM, Larry Garfield <larry@garfieldtech.com> wrote:

> A previous poster claimed that a DVCS would lead to confusion as to what the
> canonical repository was.  That is, in my experience, a common fear of
> someone who has not used a DVCS in production.

Disclaimer: I haven't committed to PHP in years, but since my last
commit, I have worked with a lot of DVCS systems.

The whole *point* of DVCS (IMNSHO) is that the concept of "canonical
repository" is part of the *problem*, not part of the *solution*.

Here's a pretty good talk by some random guy (1:10:15 worth) on the
topic about juggling lots of code sources, and canonical
"authorities", and conflicting trees:
http://www.youtube.com/watch?v=4XpnKHJAok8

(Apologies if this has already been posted upthread)

Nikita Popov

15 years ago

If a transition from SVN to Git were to be done, the question most
relevant question for me is whether it will be possible to properly
transform the EN-Revision fields in the documentation translation
files. I.e. will we be able to keep the current SVN history (just make
it a Git history) and also automatedly rewrite those EN-Revision
fields to use the appropriate sha1 hashes? I'm all in favor of using
Git, but missing EN-Revisions are really a pain and drastically
increase the time required for updating translations. I would better
keep SVN, if a transformation wouldn't be possible.

On Sun, Aug 7, 2011 at 10:50 PM, David Soria Parra <dsp@php.net> wrote:

Kiall Mac Innes

15 years ago

Hi David,

Think I may have spotted a mistake in the RFC:

Decentralized version control system have some drawbacks:

*... Snip .. *

no svn:externals, no svn:eol-style

Later on in the doc, you go into detail about submodules, and CRLF -> LF
support in both Git and Hg.

Thanks,
Kiall

On Sun, Aug 7, 2011 at 9:50 PM, David Soria Parra <dsp@php.net> wrote:

Ryan McCue

15 years ago

Kiall Mac Innes wrote:

> Later on in the doc, you go into detail about submodules, and CRLF -> LF
> support in both Git and Hg.

To be fair, submodules don't work exactly the same. Unlike
svn:externals, which are linked to a repository, submodules are linked
to a repository *and a commit*. That means that if an external is
updated, the submodule must be updated, and that change must be committed.

(Forgot to send this to the list as well, gah!)

--
Ryan McCue
<http://ryanmccue.info/>

Jordi Boggiano

15 years ago

On 08.08.2011 08:58, Ryan McCue wrote:

> Kiall Mac Innes wrote:
>> Later on in the doc, you go into detail about submodules, and CRLF -> LF
>> support in both Git and Hg.
>
> To be fair, submodules don't work exactly the same. Unlike
> svn:externals, which are linked to a repository, submodules are linked
> to a repository *and a commit*. That means that if an external is
> updated, the submodule must be updated, and that change must be committed.

The main difference is that submodules are entire repositories, while in
svn you can take sub-trees as externals.

The difference you mention is not really one, because you can do the
same in svn using 'foo -r1000 svn://somerepo' and have it fixed to one
revision, just like git does. It's a much saner approach anyway to avoid
people having out-of-sync versions of the externals.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

Ferenc Kovacs

15 years ago

On Sun, Aug 7, 2011 at 10:50 PM, David Soria Parra <dsp@php.net> wrote:

> Hi Internals,
>
> Distributed Version Control Systems (DVCS) getting more and more
> popular. In fact they have been discussed within the PHP community and
> on Internals a few times. It came to my attention that more and more
> people like to see PHP move to a DVCS to solve some of the current
> issues (and get other ones).
>
> I was asked to put together a RFC, and so here we are. I've created
> an initial draft. It is mostly based on the very good Python PEP-0374.
> It compares Git and Mercurial.
>
>    https://wiki.php.net/rfc/dvcs

I've extended the rfc with links with the previous DVCS related
discussion from the list.
I think it would be good if we could summarize the mentioned ideas and
possible problems in the RFC.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Johannes Schlueter

15 years ago

On Sun, 2011-08-07 at 16:50 -0400, David Soria Parra wrote:

> I was asked to put together a RFC, and so here we are. I've created
> an initial draft. It is mostly based on the very good Python PEP-0374.
> It compares Git and Mercurial.
>
>     https://wiki.php.net/rfc/dvcs

Two comments:

* It is said that the preferred way to get a patch from one branch
to another is by doing a merge operation in the VCS. Depending
on the timing we will most likely end up with two (trunk + 5.4)
or, more likely, three (+ 5.3) old branches which are active.
Will it be possible to merge between them using the VCS's merge
facilities or will we end up cherry-picking there? If this is
possible and we continuously merge these branches what are the
strategies for preventing specific changes from being merged
with the suggested systems (git and hg)?
* There is a section "Moving extension from/to core to/from pecl"
which seems to describe the "to core from pecl" route, not the
other way round.

johannes

Stas Malyshev

15 years ago

Hi!

On 8/8/11 9:34 AM, Johannes Schlüter wrote:

>        * It is said that the preferred way to get a patch from one branch
>          to another is by doing a merge operation in the VCS. Depending
>          on the timing we will most likely end up with two (trunk + 5.4)
>          or, more likely, three (+ 5.3) old branches which are active.
>          Will it be possible to merge between them using the VCS's merge
>          facilities or will we end up cherry-picking there? If this is

Depending on the direction of merges, it may work as merge (if you want
all changes, i.e. merging up) or as cherry-pick (if you want to merge
down). Or you may make a branch from your changes and merge it where you
like.
What's good with cherry-picking, you can still have full commits so you
know who did it and why and can relate to the original source.

>          possible and we continuously merge these branches what are the
>          strategies for preventing specific changes from being merged
>          with the suggested systems (git and hg)?

I'd suggest putting changes always in the lowest (oldest) branch first
and then merge the branches up to newest. This way we ensure the changes
are always in sync. But there can be challenges if there is substantial
code change between branches, of course, so sometimes we'd have to
cherry-pick or even do something more interactive, git merge is good but
not *that* good :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Joey Smith

15 years ago

On Mon, Aug 08, 2011 at 10:44:12AM -0700, Stas Malyshev wrote:

> Hi!
>
> On 8/8/11 9:34 AM, Johannes Schlüter wrote:
> >       * It is said that the preferred way to get a patch from one branch
> >         to another is by doing a merge operation in the VCS. Depending
> >         on the timing we will most likely end up with two (trunk + 5.4)
> >         or, more likely, three (+ 5.3) old branches which are active.
> >         Will it be possible to merge between them using the VCS's merge
> >         facilities or will we end up cherry-picking there? If this is
>
> Depending on the direction of merges, it may work as merge (if you
> want all changes, i.e. merging up) or as cherry-pick (if you want to
> merge down). Or you may make a branch from your changes and merge it
> where you like.
> What's good with cherry-picking, you can still have full commits so
> you know who did it and why and can relate to the original source.
>
> >         possible and we continuously merge these branches what are the
> >         strategies for preventing specific changes from being merged
> >         with the suggested systems (git and hg)?
>
> I'd suggest putting changes always in the lowest (oldest) branch
> first and then merge the branches up to newest. This way we ensure
> the changes are always in sync. But there can be challenges if there
> is substantial code change between branches, of course, so sometimes
> we'd have to cherry-pick or even do something more interactive, git
> merge is good but not *that* good :)

I've been a long-time fan of the "nvie" git workflow laid out at [1].
In fact, if you're using git as your DVCS, there's even a bunch of
"porcelain" [2] to make it easier to manage your trees.

I'm not saying that other tools aren't capable of the same workflow,
just pointing out one solution that I've found works pretty well in
real-world environments.


[1] http://nvie.com/posts/a-successful-git-branching-model/
[2] https://github.com/nvie/gitflow

Ryan McCue

15 years ago

Joey Smith wrote:

> In fact, if you're using git as your DVCS, there's even a bunch of
> "porcelain" [2] to make it easier to manage your trees.

Side note: For anyone not familiar with Git terminology: "plumbing" is
all the commands that alter the repository, while "porcelain" are tools
built on top of that (such as the "commit", "push", "pull", "merge"
commands that people would be familiar with).

--
Ryan McCue
<http://ryanmccue.info/>

Joey Smith

15 years ago

On Sun, Aug 07, 2011 at 04:50:55PM -0400, David Soria Parra wrote:

> Hi Internals,
>
> NOTE: this is not the place for any religiouise discussion about git vs
> mercurial whatsover. if you have nothing else to add than "hg is $***
> anyway" or think hosting platform XY will solve all our problems
> without reading the RFC carefully, please post to alt.relgion.* and not
> here.
>
>
> - David

I feel like maybe the RFC throws in the towel too early on the idea of
using SSH keys to manage access control. On the git side, there's a tool
called gitolite which makes management of access controls via SSH keys
incredibly trivial. While I've never looked at the code behind the online
"Manager Users" tool we have, I can't imagine it would be terribly hard to
expand that to allow people to add their public SSH keys for plugging into
gitolite [1].

[1] https://github.com/sitaramc/gitolite

David Soria Parra

15 years ago

On 2011-08-07, David Soria Parra <dsp@php.net> wrote:

> Hi Internals,
>
> Distributed Version Control Systems (DVCS) getting more and more
> popular. In fact they have been discussed within the PHP community and
> on Internals a few times. It came to my attention that more and more
> people like to see PHP move to a DVCS to solve some of the current
> issues (and get other ones).
>
> I was asked to put together a RFC, and so here we are. I've created
> an initial draft. It is mostly based on the very good Python PEP-0374.
> It compares Git and Mercurial.
>
>     https://wiki.php.net/rfc/dvcs
>

I added some notes about Karma and implemented Karma for Mercurial.
If there are no more questions (maybe I forgot some to answer), I will
go and call for votes this week.

Stas Malyshev

15 years ago

Hi!

On 8/12/11 1:55 AM, David Soria Parra wrote:

> I added some notes about Karma and implemented Karma for Mercurial.
> If there are no more questions (maybe I forgot some to answer), I will
> go and call for votes this week.

I think we shouldn't rush with it, things still are being discussed as I
see.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Kalle Sommer Nielsen

15 years ago

Ho

2011/8/7 David Soria Parra <dsp@php.net>:

> ...

Normally not my cup of coffee entering a threat on which VCS we should
use, I honestly can't see why we didn't choose another over SVN when
we had a year long discussion about it. I remember Rasmus said that
when we change version control system: "it better last another 10
years" like CVS did.

I can't see why we can't offer mirrors that can be written to and
synced for people who absolutely cannot work inside a centralized
system like our current model. I would really, really hate to
re-install and re-configure my whole development environment and the
why I develop because we simply cannot get along with a system that
had the majority of the voting back then, which I'm deadly against.
It's just like here in Denmark where people said no to the Euro
currency and the politicians wants to have more votings because they
did not get their will last time. Okay maybe thats a bit over the line
of what we have here, but I honestly don't see that religious hate
against this model which works absolutely fine.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Sebastian Bergmann

15 years ago

On 08/12/2011 07:38 AM, Kalle Sommer Nielsen wrote:

> Normally not my cup of coffee entering a threat on which VCS we should
> use, I honestly can't see why we didn't choose another over SVN when
> we had a year long discussion about it. I remember Rasmus said that
> when we change version control system: "it better last another 10
> years" like CVS did.

I never understood why we chose a legacy technology when we migrated
from CVS.

--
Sebastian Bergmann                    Co-Founder and Principal Consultant
http://sebastian-bergmann.de/                           http://thePHP.cc/

Kalle Sommer Nielsen

15 years ago

2011/8/12 Sebastian Bergmann <sebastian@php.net>:

>  I never understood why we chose a legacy technology when we migrated
>  from CVS.

Well I'm sure if there were raised bigger "concerns" or more attention
headed towards Git/Mercurial/Bzr/Whatever then we might ended up on
one of them today. I don't remember much of the discussion other than
it was moved to another list which I didn't subscribe to, I just
remember it was long and ongoing with our beloved namespace separator
at the same time which floated internals.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Gwynne Raskind

15 years ago

On Fri, Aug 12, 2011 at 07:54, Kalle Sommer Nielsen <kalle@php.net> wrote:

> 2011/8/12 Sebastian Bergmann <sebastian@php.net>:
>>  I never understood why we chose a legacy technology when we migrated
>>  from CVS.
>
> Well I'm sure if there were raised bigger "concerns" or more attention
> headed towards Git/Mercurial/Bzr/Whatever then we might ended up on
> one of them today. I don't remember much of the discussion other than
> it was moved to another list which I didn't subscribe to, I just
> remember it was long and ongoing with our beloved namespace separator
> at the same time which floated internals.

The short version is that those in charge of the move (mostly me)
didn't understand DVCS at the time.

In retrospect, it was a bad move. Git and Hg were less mature back in
early 2009, but not so immature that we couldn't have used either one.
Between the lack of interest in SVN and the ongoing debate over the
namespace separator, there weren't enough voices talking about VCS to
make a difference - I argued that CVS -> SVN was complicated enough
and that jumping straight to DVCS would upset too many people, and
there was enough agreement that SVN went ahead anyway, with the
thought that the Git mirror would be "good enough".

In my defense, at the time SVN looked a good bit better than it does
now. I really did think it'd last, LOL.

-- Gwynne

Stas Malyshev

15 years ago

Hi!

On 8/12/11 4:38 AM, Kalle Sommer Nielsen wrote:

> I can't see why we can't offer mirrors that can be written to and
> synced for people who absolutely cannot work inside a centralized
> system like our current model. I would really, really hate to

You don't want to deal with syncing writable mirrors in SVN. You really
don't. SVN is not good at it. That's why DCVSes were born.

> re-install and re-configure my whole development environment and the
> why I develop because we simply cannot get along with a system that
> had the majority of the voting back then, which I'm deadly against.

Come on, how much reinstall is that? One checkout? Unless you have big
setup of tools around your php repo, for you the move will be mostly
inside your head (learning new commands), rather inside your computer.

> It's just like here in Denmark where people said no to the Euro
> currency and the politicians wants to have more votings because they

How about we leave politics out of the list before we have a good old
flamewar here? :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227