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

13 years ago by Richard Quadling — view source

unread

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

13 years ago by David Soria Parra — view source

unread

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

13 years ago by johannes@schlueters.de — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Derick Rethans — view source

unread

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

13 years ago by Adam Harvey — view source

unread

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Keloran — view source

unread

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

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

13 years ago by Ferenc Kovacs — view source

unread

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by johannes@schlueters.de — view source

unread

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Nathaniel Catchpole — view source

unread

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

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 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<http://www.firebirdsql.org/index.php

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Matthew Weier O'Phinney — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Justin Rovang — view source

unread

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.

Hi!

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.

13 years ago by Richard Quadling — view source

unread

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Herman Radtke — view source

unread

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

I think any kind of RFC vote is going to meet a lot of resistance
simply based on the fact that a lot of people on this list do not
appear to be very familiar with dvcs and the pros and cons of moving
to one of the dvcs offerings. Trying to find the best solution in
terms of technology (git vs hg), structure, workflow, etc is an effort
in futility at this point.

I think it would be better to pilot some different options and ease
people into the transition from a vcs to a dvcs. One idea that springs
to mind is allowing pecl packages to live on google code, github or
bitbucket. That allows developers to freely play around with svn, git
or hg. While that may seem odd, some of us are already doing it (ex:
https://github.com/andreiz/php-memcached). I am sure this brings up
all sorts of problems and issues, but that is the point. Moving svn to
a dvcs is less of a technical change and more of a paradigm shift in
the fundamental way a user interacts with version control.

As a long time dvcs proponent and user, I support the move to
distributed version control. I just hope it is done right.

--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com

13 years ago by Stas Malyshev — view source

unread

Hi!

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'

I think they're describing local modifications for the Drupal site
there, not developing Drupal. Think about it: suppose we have Drupal
versions 7.0, 7.1, 7.2. Those will be branches. But if you want to do
something into each of them, it won't do for each developer to create a
private branch for each of them - the amount of branches will quickly
get out of control. That's when you'd need forks.

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

13 years ago by Lester Caine — view source

unread

Stas Malyshev 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.

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

I think they're describing local modifications for the Drupal site
there, not developing Drupal. Think about it: suppose we have Drupal
versions 7.0, 7.1, 7.2. Those will be branches. But if you want to do
something into each of them, it won't do for each developer to create a
private branch for each of them - the amount of branches will quickly
get out of control. That's when you'd need forks.

Actually they are talking about developing Drupal ... "Once you have finished
working on your fix or feature, you’ll need to bring those changes from your
topic branch back into the main fooproject branch."
Bare in mind that this is more like PEAR code than compiled C code, so the end
target is different but the process is what matters. I'm not sure that is the
right way to be doing this process, but if it's what is documented?

As Herman says ... "Moving svn to a dvcs is less of a technical change and more
of a paradigm shift in the fundamental way a user interacts with version control."
There are many ways that DVCS can be abused, so managing things in an agreed
manner is more what needs to be agreed than the simple - switch to DVCS?

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

13 years ago by Kiall Mac Innes — view source

unread

Actually they are talking about developing Drupal ...

The Drupal document referenced is not explaining "How to develop Drupal" but
rather "How to develop a drupal based site using git".

The section titled "Creating a Working
Branch"'s introductory sentence reads:

Now, you need a branch where you can track not only Drupal core, but also

all of the contributed and custom modules and themes for your site.

The "Once you have finished working on your fix or feature, you’ll need to
bring those changes from your topic branch back into the main fooproject
branch." comment is referring to bringing a fix/feature back into your
site's codebase, from a branch of your own codebase.

Drupal does have several documents on how to contribute fixes/features to
Drupal itself - Here's one of them: http://drupal.org/node/707484

Kiall

13 years ago by Lester Caine — view source

unread

Kiall Mac Innes wrote:

The Drupal document referenced is not explaining "How to develop Drupal" but rather "How to develop a drupal based site using git".
Actually in my book that is one of the same thing once we move to more complex
sites. Parts of my own sites ARE packages under development in parallel with the
main code tree, and while developing one invariably bugs are fixed in the main
tree which need to be pushed back. This is precisely why I needed DVCS here, and
managing and updating sites via Hg is working well.

Drupal does have several documents on how to contribute fixes/features
to Drupal itself
Actually the whole documentation tree is looking pretty good
http://drupal.org/documentation/git

But it still does not convince me that I made the wrong choice switching to Hg,
and I can still pick up anything I want from the Drupal repos anyway.

At the end of the day, it's the whole infrastructure that needs to be agreed on,
and I suspect that the Drupal model could be simply cloned into php.net?
Irritating for some of us, but it can be lived with. I just think that it's a
bit like Windows - everybody uses it despite it's faults - and simply work
around it's faults. For me the very poor cross platform integration and support
in Eclipse was a show stopper several months ago, so my own base is now 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

13 years ago by Pierre Joye — view source

unread

Actually they are talking about developing Drupal ...

It seems to have a confusion between forks used for development by
individuals and (so called) official branches.

99% of the time one does not care about the forks but when a pull
request is done from it (see it as a patch being sent to the
list/issue tracker).

A fork is also a very good way to work on non trivial changes for a
given period without having to leave the official branches in a non
stable or unfinished state. And even more important, it can be done
publicly with history, etc. That alone is very valuable and much more
easier than having to either maintain mirrors or local repository
(with all disadvantages when it gets out of sync with the main repo).

About branching, tagging or developing using a DVCS, I can only
recommend to read the doc linked in this rfc:

http://nvie.com/posts/a-successful-git-branching-model/

It explains one model which has been proven to work pretty well.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Lester Caine — view source

unread

Pierre Joye wrote:

It seems to have a confusion between forks used for development by
individuals and (so called) official branches.
Looking back, the point that I was not explaining very well was the fact that
people seem to think that they need to create a fork into their on-line account
before cloning to the local copy. On the whole these are not needed, and the
'sandbox' approach for sharing tangential work seems better? Similarly
extensions like apt have their own subrepo which can be worked on independent to
the bulk of the code base?

About branching, tagging or developing using a DVCS, I can only
recommend to read the doc linked in this rfc:

http://nvie.com/posts/a-successful-git-branching-model/

It explains one model which has been proven to work pretty well.
This model is ideal for a main trunk. The major advantage to DVCS is being able
to work on things like PECL modules and even core extensions in parallel to the
main core. It is only recently that git and hg have finally supported 'subrepo'
and I see this as the ideal model for my own work. I can create a superproject
which just combines the extensions (php and third party!) that I am using and
almost manage them nicely. There are still a few rough edges to this since
neither git nor hg have been convinced that it is an important requirement ...
they don't use it themselves which seems strange when their own code base has
many third party elements? I don't see 'feature branches' as the correct way to
handle what are essentially self contained elements?

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

13 years ago by Michael Grunert — view source

unread

Looking back, the point that I was not explaining very well was the fact
that people seem to think that they need to create a fork into their
on-line account before cloning to the local copy. On the whole these are
not needed, and the 'sandbox' approach for sharing tangential work seems
better? Similarly extensions like apt have their own subrepo which can
be worked on independent to the bulk of the code base?

Just to throw in some comment, you did a really good job to confuse
people in this thread. In the beginning i really got the impression you
were totally against dvcs and now you praise them and argue in their
favor against people who want them too .. maybe i just misread some of
the mails but thats my overall impression so far ..

About branching, tagging or developing using a DVCS, I can only
recommend to read the doc linked in this rfc:

http://nvie.com/posts/a-successful-git-branching-model/

It explains one model which has been proven to work pretty well.
This model is ideal for a main trunk. The major advantage to DVCS is
being able to work on things like PECL modules and even core extensions
in parallel to the main core. It is only recently that git and hg have
finally supported 'subrepo' and I see this as the ideal model for my own
work. I can create a superproject which just combines the extensions
(php and third party!) that I am using and almost manage them nicely.
There are still a few rough edges to this since neither git nor hg have
been convinced that it is an important requirement ... they don't use it
themselves which seems strange when their own code base has many third
party elements? I don't see 'feature branches' as the correct way to
handle what are essentially self contained elements?

So did you read the workflow document? I do have some doubt there ..
A "feature branch" does not refer to some self contained element you
could or even should place into a subrepo like a pecl extension or
module. A "feature branch" is meant for a distinct unit of work, like a
new feature or a bug fix that has to be merged with the main branch
sometime in the future anyways. As soon as this feature or bug fix has
been completed the feature branch dies/dries up .. which is obviously
bad in something like svn as those branches would clutter up the
repository but can be handled really good in dvcs as the new branches
are only local or in some loosely coupled public forks/clones and can be
pulled/pushed into the "main repo" as needed.

just my 2 cents before i get a headache from this

Regards,

Michael

13 years ago by Lester Caine — view source

unread

Michael Grunert wrote:

Looking back, the point that I was not explaining very well was the fact
that people seem to think that they need to create a fork into their
on-line account before cloning to the local copy. On the whole these are
not needed, and the 'sandbox' approach for sharing tangential work seems
better? Similarly extensions like apt have their own subrepo which can
be worked on independent to the bulk of the code base?

Just to throw in some comment, you did a really good job to confuse
people in this thread. In the beginning i really got the impression you
were totally against dvcs and now you praise them and argue in their
favor against people who want them too .. maybe i just misread some of
the mails but thats my overall impression so far ..

I don't have a problem with DVCS, just with projects ploughing into using git a
year ago when it was ( and still is ) not ready for those type of projects :(
It was a case of having to work with it at a time when cross platform tools were
not available, and subrepo's did not exist.
I have a nice working hg setup that works transparently from Linux and Windows
and runs in parallel with my Eclipse development platform. But even that still
has not restored some of the excellent tools that CVS and SVN provide in
Eclipse. MANY of the complaints about CVS and SVN were never a problem when one
used Eclipse. At some point I expect the same facilities to be restored to
Eclipse, but currently TortoiseHg runs in parallel neatly. I don't have to
switch between different tools on the different platforms.

About branching, tagging or developing using a DVCS, I can only
recommend to read the doc linked in this rfc:

http://nvie.com/posts/a-successful-git-branching-model/

It explains one model which has been proven to work pretty well.
This model is ideal for a main trunk. The major advantage to DVCS is
being able to work on things like PECL modules and even core extensions
in parallel to the main core. It is only recently that git and hg have
finally supported 'subrepo' and I see this as the ideal model for my own
work. I can create a superproject which just combines the extensions
(php and third party!) that I am using and almost manage them nicely.
There are still a few rough edges to this since neither git nor hg have
been convinced that it is an important requirement ... they don't use it
themselves which seems strange when their own code base has many third
party elements? I don't see 'feature branches' as the correct way to
handle what are essentially self contained elements?

So did you read the workflow document? I do have some doubt there ..
A "feature branch" does not refer to some self contained element you
could or even should place into a subrepo like a pecl extension or
module. A "feature branch" is meant for a distinct unit of work, like a
new feature or a bug fix that has to be merged with the main branch
sometime in the future anyways. As soon as this feature or bug fix has
been completed the feature branch dies/dries up .. which is obviously
bad in something like svn as those branches would clutter up the
repository but can be handled really good in dvcs as the new branches
are only local or in some loosely coupled public forks/clones and can be
pulled/pushed into the "main repo" as needed.
Again, I'm not explaining things very well ...
What will not work moving forward is a simple dump of the entire SVN history
into a single git repository. What is needed is a managed way to create a series
of subrepos for each of the packages that make up PHP. PECL and PEAR packages
then just become extra subrepos which are included or not in the superproject
trunk. The 'single repo' camp point to "feature branch" as a way of handling
that work in a single module without having to breaking up the repo, but to my
mind that is simply wrong? Starting from a point of separate repo's simply
allows a lot easier management of everything and we can work on areas that we
want to without having to clone the whole code base? Moving things in and out of
the core distribution is then just a matter of adding or removing the subrepo to
the master project.

just my 2 cents before i get a headache from this
I had that for 6 months until I realised that I could simply ignore git and run
everything via hg - using hggit :)

Moving to DVCS is not the problem. It's doing it in a way that works well for PHP!

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

13 years ago by Kiall Mac Innes — view source

unread

I don't have a problem with DVCS, just with projects ploughing into using
git a year ago when it was ( and still is ) not ready for those type of
projects :(

I think you're talking about submodules not being ready - correct me if I'm
wrong.

We (the Kohana http://kohanaframework.org framework and my company) use
git submodules very successfully to track isolated parts of the code.
Submodules work perfectly.

https://github.com/kohana/kohana/blob/3.2%2Fmaster/.gitmodules

It was a case of having to work with it at a time when cross platform tools

were not available, and subrepo's did not exist.

I've occasionally used msysgit on windows for Kohana development - cross
platform submodules have work perfectly for years!

And - I've never heard a complaint from anyone about Git for OS X / Linux
not working correctly.

I have a nice working hg setup that works transparently from Linux and
Windows and runs in parallel with my Eclipse development platform. But even
that still has not restored some of the excellent tools that CVS and SVN
provide in Eclipse. MANY of the complaints about CVS and SVN were never a
problem when one used Eclipse. At some point I expect the same facilities to
be restored to Eclipse, but currently TortoiseHg runs in parallel neatly. I
don't have to switch between different tools on the different platforms.

In my experience, no GUI VCS tools (for Git/SVN/CVS) have ever measured up
to the easy of use, and power of the CLI versions. And honestly - I think
choosing a VCS based on the available GUI tools is poor decision making. New
and improved GUI's will continue to be released, while the core VCS will
remain a relatively stationary target.

Again, I'm not explaining things very well ...

What will not work moving forward is a simple dump of the entire SVN
history into a single git repository. What is needed is a managed way to
create a series of subrepos for each of the packages that make up PHP.

This has been briefly discussed in the RFC, and I believe the intention is
to cover that in detail in a second "Migration RFC". I don't believe anyone
is suggesting a simple dump of SVN into Git/Hg.

PECL and PEAR packages then just become extra subrepos which are included
or not in the superproject trunk. The 'single repo' camp point to "feature
branch" as a way of handling that work in a single module without having to
breaking up the repo

I don't believe that's what anybody is suggesting (besides - I think - the
Drupal document you referenced).

I believe people are suggesting that feature/topic branches might be used
within a single repo. For example the pecl APC repo might have a "master"
(trunk) branch, and a "feature/persistent-opcode-cache" branch.

Kiall

13 years ago by Kiall Mac Innes — view source

unread

Thanks,
Kiall

On Sat, Aug 13, 2011 at 9:43 AM, Michael Grunert <
Michael.Grunert@s1998.tu-chemnitz.de> wrote:

Looking back, the point that I was ...[snip]

Just to throw in some comment, you did a really good job to confuse people
in this thread. In the beginning i really got the impression you were
totally against dvcs and now you praise them and argue in their favor
against people who want them too .. maybe i just misread some of the mails
but thats my overall impression so far ..

I have to agree with you on this - I for one have been very confused by
Lester's comments!

One choice example I've just realised, is most of us are taking about the
workflows of Git/Hg for PHP itself, sometimes using PHP based projects as
simple workflow examples.

On the other hand, Lester appears to be talking about developing sites with
PHP:

Lester Caine wrote:

Kiall Mac Innes wrote:

The Drupal document referenced is not explaining "How to develop Drupal"
but rather "How to develop a drupal based site using git".

Actually in my book that is one of the same thing once we move to more
complex sites. Parts of my own sites ARE packages under development in
parallel with the main code tree, and while developing one invariably bugs
are fixed in the main tree which need to be pushed back.

Kiall

13 years ago by Lester Caine — view source

unread

Kiall Mac Innes wrote:

I have to agree with you on this - I for one have been very confused by
Lester's comments!

One choice example I've just realised, is most of us are taking about the
workflows of Git/Hg for PHP itself, sometimes using PHP based projects as
simple workflow examples.

It does depend where you separate the C code from the PHP ... but with the right
workflow it should not matter which code is being worked on? Just developing a
process that only handles C development then ignores the PEAR arm. Once one
covers that, there is little difference to managing the development of the whole
site set-up. In theory the DVCS could also manage all of the documentation as well.

I'm playing with C and C++ code in parallel to the PHP, javascript, and other
web languages and in addition java and python to improve the tools such as
PHPEclipse and Hg itself. It's only in the last month or so ( since hg1.9 and
other updates ) that the whole package has started to flow as well as the
original CVS workflow that has been fine for me for 10+ years ...

Eclipse has provided a clean stable platform across both Linux and Windows so
I've never actually had to learn command line stuff. Both git and hg are
essentially command line tools which are only now being supported by the same
extended facilities that CVS and SVN have had for many years! A year ago there
was a very clear distinction between git and hg once one moved away from the
command line, but on the command line there was very little difference? Nowadays
things are a lot tighter, but none of the options stand out as the right
solution, they all have as many negatives as positives, so the target should be
a process that does not prevent any DVCS client from being used. If the master
is on git then so be it, just don't then put in place processes that prevent hg
or one of the other DVCS systems from cooperating as well?

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

13 years ago by Larry Garfield — view source

unread

Stas Malyshev wrote:

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

I think they're describing local modifications for the Drupal site
there, not developing Drupal. Think about it: suppose we have Drupal
versions 7.0, 7.1, 7.2. Those will be branches. But if you want to do
something into each of them, it won't do for each developer to create a
private branch for each of them - the amount of branches will quickly
get out of control. That's when you'd need forks.

Actually they are talking about developing Drupal ... "Once you have
finished working on your fix or feature, you’ll need to bring those
changes from your topic branch back into the main fooproject branch."
Bare in mind that this is more like PEAR code than compiled C code, so
the end target is different but the process is what matters. I'm not
sure that is the right way to be doing this process, but if it's what
is documented?

One of the important features of Git (although some might ague that it's
a design flaw; I see it as a feature) is that it does not impose a
specific workflow on you. There are easily a half dozen good git-based
workflows depending on your development model, as well as at least a
dozen bad ones. :-)

The GitHub model in particular actively encourages forking and "no
canonical repository". You can know that a given series of repos are
cloned from another given repo, but that doesn't intrinsically say which
is the canonical repo. You have to just collectively agree on that.
That also encourages contribution in one of two ways:

Fork, clone your fork to your own computer, make changes, push, file
pull request. (Good for one person working but not for open peer review.)
Get commit access to the "main" repository, clone it to your
computer, make changes, merge, push. (Good for a small team that allows
lots of people to commit to the mainline.)

Drupal is still relatively new to Git, and we have a patch-based
peer-review culture. For now we're using Git essentially like CVS with
fewer bugs. :-) The primary workflow for contribution is: Clone the
official repository to your computer, branch, make changes, make a patch
out of those, post to the issue queue for review, and the maintainer
commits and pushes it to his clone. We want to eventually move to every
issue having its own public read/write repository, but we haven't built
the infrastructure for that yet.

The key point there is that in Drupal, Drupal core and any given module
have a very clear official repository with very limited commit access.
There's only 2 people with commit access to Drupal itself right now,
compared to the 1000+ of PHP. Most modules have one, perhaps two people
with commit access. Everything else happens in the issue queues via
patches. We do have "unofficial repositories" that can be used for
personal forks a la GitHub, but that's not an official
infrastructure-supported feature yet. (Eventually, we hope.)

If PHP were to go Git, it would probably want to custom build a server
much like Drupal has with its own workflow model. Probably the biggest
advantage, though, is the ability to block "large" commits to mainline
until they're approved by the release manager for a given version but
without limiting people's ability to experiment. With Git, people can
experiment with unofficial, official, quasi-official, or one-off
complete repositories before or after making them "public", either for
review or merging into mainline, and it's all really really easy.

Submodules may make sense for PHP/PECL. I'm not sure. That would
likely take the form of a series of repositories, one for each PECL
module, much the way Drupal has for its modules. Then the PHP core
repository would include a submodule reference to the PECL modules that
were considered "in core" at any given time. Moving a module into/out
of PHP itself is then just a matter of adding/removing submodule
references. (Drupal does not do that currently for its core-packaged
modules, but in theory we could.)

I do think that Git would be a smart move for PHP; any limitations that
the GitHub model imposes are just that, impositions of the GitHub
model. There's no reason that Git has to be used in that fashion if
some other model would fit PHP better.

--Larry Garfield

13 years ago by Lester Caine — view source

unread

Larry Garfield wrote:

Submodules may make sense for PHP/PECL. I'm not sure. That would
likely take the form of a series of repositories, one for each PECL
module, much the way Drupal has for its modules. Then the PHP core
repository would include a submodule reference to the PECL modules that
were considered "in core" at any given time. Moving a module into/out
of PHP itself is then just a matter of adding/removing submodule
references. (Drupal does not do that currently for its core-packaged
modules, but in theory we could.)

There are large areas of the core of PHP which are naturally submodules (
subrepo in hg ). Currently we can all build PHP only using those extensions that
we need. When I build my own versions, everything db wise other than Firebird is
switched off, so all of the extensions that Linux distributions provide as
individually loaded modules are naturally submodules in the core structure?
Currently I only bother about code in the modules I actually use, so being able
to build my own superproject direct from the repo would be useful and I can now
even build that on windows.

hg can equally do all of the same stuff as git with all the same points being
made. I don't see github as being any + for git simply because I think one of
the developments has to be, as Larry says, a privately managed DVCS system so
that the access control can be maintained? ( A year ago votes on other projects
choose git simply because of github :( ) At that point I do think that hg's
design and plugin structure makes it a lot easier to expand? Certainly when it
comes to maintaining the Karma system. If people then want a git view as well
that can be generated as a mirror? I'm not sure that git supports the same level
of interoperability as hg, bazaar and the others, many of which transparently
read git repos. But I think that submodule/subrepo is an area where the cross
DVCS functionality starts to fall apart. Currently I build an hg superproject
calling each git repo rather than using a git repo with submodules. This may be
why git wins out again for the base since hg is a lot happier to simply talk to
that than the other way around?

The only real disadvantage to hg is having to handle python code to maintain it,
people might start converting from PHP ;) Although phphgadmin is a start to
improving the php interface support and could be a good start at a fully PHP
managed interface to a PHP repo?

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

13 years ago by Gwynne Raskind — view source

unread

The only real disadvantage to hg is having to handle python code to maintain
it, people might start converting from PHP ;) Although phphgadmin is a start
to improving the php interface support and could be a good start at a fully
PHP managed interface to a PHP repo?

I'm starting to think we should take a cue from Linus and just do as
we did with bugsweb, newsweb, and so forth: Build our own
(Hg/Git-compatible) DVCS from scratch!

(I'm joking... mostly.)

-- Gwynne

13 years ago by Lester Caine — view source

unread

Gwynne Raskind wrote:

The only real disadvantage to hg is having to handle python code to maintain

it, people might start converting from PHP;) Although phphgadmin is a start
to improving the php interface support and could be a good start at a fully
PHP managed interface to a PHP repo?
I'm starting to think we should take a cue from Linus and just do as
we did with bugsweb, newsweb, and so forth: Build our own
(Hg/Git-compatible) DVCS from scratch!

(I'm joking... mostly.)
It's not such a silly idea ... In reality both git and hg get modified to
provide custom facilities, so creating at least a clean php based front end to a
DVCS engine makes perfect sense. Especially if it links in with bugsweb and
perhaps highlights hotfix or other patch information directly in the code base?
Commits tag the relevant bug report automatically? And patch accepts both hg and
git inputs for those without karma, or would commit for those with?

I have been more than happy with hg working into git repos I did simply assume
that there would be an extension for git to handle hg in the same way, but it
would appear not? As far as I can tell from the hggit extension, mirroring the
git information is not particularly difficult, so a 'hybrid' that could provide
both hg.php.net and git.php.net views seems practical, and commits need to be
managed via karma, so processing that should not be difficult? But the problem
area I still see is the handling of submodule/subrepo commits where they cross
several submodules ... that was an area where custom scripts used to exist for a
couple of the projects I work with and I think THIS may be an area where a
scratch built interface may be a possible option.

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

13 years ago by Justin Rovang — view source

unread

Gwynne Raskind wrote:

The only real disadvantage to hg is having to handle python code to
maintain

it, people might start converting from PHP;) Although phphgadmin is
a start
to improving the php interface support and could be a good start at
a fully
PHP managed interface to a PHP repo?
I'm starting to think we should take a cue from Linus and just do as
we did with bugsweb, newsweb, and so forth: Build our own
(Hg/Git-compatible) DVCS from scratch!

(I'm joking... mostly.)
It's not such a silly idea ... In reality both git and hg get modified
to provide custom facilities, so creating at least a clean php based
front end to a DVCS engine makes perfect sense. Especially if it links
in with bugsweb and perhaps highlights hotfix or other patch information
directly in the code base? Commits tag the relevant bug report
automatically? And patch accepts both hg and git inputs for those
without karma, or would commit for those with?

I have been more than happy with hg working into git repos I did simply
assume that there would be an extension for git to handle hg in the same
way, but it would appear not? As far as I can tell from the hggit
extension, mirroring the git information is not particularly difficult,
so a 'hybrid' that could provide both hg.php.net and git.php.net views
seems practical, and commits need to be managed via karma, so processing
that should not be difficult? But the problem area I still see is the
handling of submodule/subrepo commits where they cross several
submodules ... that was an area where custom scripts used to exist for a
couple of the projects I work with and I think THIS may be an area where
a scratch built interface may be a possible option.

If one is made from scratch, I propose calling it "Phit"!

Submodule support in both still leaves something to be desired. Instead
of divergence, a large project like PHP could swing enough influence and
developer base to benefit development for one or both of the DVCS's.
(Probably a pipe dream :o )

13 years ago by Matthew Weier O'Phinney — view source

unread

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

13 years ago by johannes@schlueters.de — view source

unread

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

13 years ago by Sebastian Bergmann — view source

unread

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/

13 years ago by Sean Coates — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Stas Malyshev — view source

unread

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.

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.
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 :)
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

13 years ago by David Soria Parra — view source

unread

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.

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.

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

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)

13 years ago by Richard Riley — view source

unread

David Soria Parra dsp@php.net writes:

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.

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.

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

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.

13 years ago by Stefan Neufeind — view source

unread

David Soria Parra dsp@php.net writes:

[...]

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

13 years ago by Ferenc Kovacs — view source

unread

David Soria Parra dsp@php.net writes:

[...]

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

--

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

13 years ago by Kiall Mac Innes — view source

unread

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

David Soria Parra dsp@php.net writes:

[...]

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

--

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

13 years ago by Stefan Neufeind — view source

unread

David Soria Parra dsp@php.net writes:

[...]

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

13 years ago by Hannes Landeholm — view source

unread

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Lester Caine — view source

unread

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

13 years ago by Kiall Mac Innes — view source

unread

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

13 years ago by Ryan McCue — view source

unread

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/

13 years ago by Larry Garfield — view source

unread

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.

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.

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

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

13 years ago by Ronald Chmara — view source

unread

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)

13 years ago by Nikita Popov — view source

unread

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.

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

13 years ago by Kiall Mac Innes — view source

unread

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

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

13 years ago by Ryan McCue — view source

unread

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/

13 years ago by Jordi Boggiano — view source

unread

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

13 years ago by Ferenc Kovacs — view source

unread

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

13 years ago by johannes@schlueters.de — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

   * 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

13 years ago by Joey Smith — view source

unread

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

13 years ago by David Soria Parra — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Kalle Sommer Nielsen — view source

unread

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

13 years ago by Sebastian Bergmann — view source

unread

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/

13 years ago by Kalle Sommer Nielsen — view source

unread

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

13 years ago by Gwynne Raskind — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

Hi!

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

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

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.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

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

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.

-- Lester Caine - G8HFL

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.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

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.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

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

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

-- Lester Caine - G8HFL

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

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.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

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

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.

--
Lester Caine - G8HFL

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.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

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.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

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

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

--
Lester Caine - G8HFL

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