On 2011-08-12, Lester Caine les...@lsces.co.uk wrote:
Ferenc Kovacs wrote:
But you can't call it PHP anymore due to the license, where as with a
DCVS with people having forks on publically accessible repositories,
everybody is basically violating the license.
you can rename
On 2011-08-12, Lester Caine les...@lsces.co.uk wrote:
Johannes Schlüter wrote:
Actually the real question here is WHY create a fork on github
at all? The copy you are working on LOCALLY is the fork that you
are developing on? Much of the stuff on github and the other
DVCS server
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
On Sun, Aug 14, 2011 at 04:18, Lester Caine les...@lsces.co.uk 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
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?
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
On Sat, Aug 13, 2011 at 1:51 AM, Kiall Mac Innes ki...@managedit.ie wrote:
On Sat, Aug 13, 2011 at 12:26 AM, Lester Caine les...@lsces.co.uk wrote:
Actually they are talking about developing Drupal ...
It seems to have a confusion between forks used for development by
individuals and (so
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
On 08/13/2011 10:02 AM, Lester Caine 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'
Michael Grunert wrote:
On 08/13/2011 10:02 AM, Lester Caine 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,
Thanks,
Kiall
On Sat, Aug 13, 2011 at 9:43 AM, Michael Grunert
michael.grun...@s1998.tu-chemnitz.de wrote:
On 08/13/2011 10:02 AM, Lester Caine 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.
On Sat, Aug 13, 2011 at 10:33 AM, Lester Caine les...@lsces.co.uk wrote:
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 -
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
On 08/12/2011 06:26 PM, Lester Caine wrote:
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
On Sun, 7 Aug 2011, Stas Malyshev wrote:
On 8/7/11 2:13 PM, Richard Quadling wrote:
You can build single-source workflows around DCVS too. The fact that
everybody is keeping the copy of the history doesn't mean there can't
be one main repository. The point of DCVS is not as much in doing
On 12 August 2011 18:26, Derick Rethans der...@php.net wrote:
I share Richard's concerns about finding out what is the real one/best
one/latest one.
I didn't understand the problem when Richard first posted, and I still
don't now, to be honest. The canonical repository is the one the
php.net
all of those you listed, when you look at the fork path, can be traced to
the real root, but thats the point to git, the main might have a bug, and
becasue you can fork, and give pull-requests, until main is fixed, yours
could be counted as the real one
On Fri, Aug 12, 2011 at 11:26 AM, Derick
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
On Fri, 2011-08-12 at 11:26 +0100, Derick Rethans wrote:
But you can't call it PHP anymore due to the license, where as with a
DCVS with people having forks on publically accessible repositories,
everybody is basically violating the license.
If this kind of a fork makes it a product as the
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
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
Ho
2011/8/7 David Soria Parra d...@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:
On 08/12/2011 06:26 AM, Derick Rethans wrote:
I share Richard's concerns about finding out what is the real one/best
one/latest one.
I do not think of the network of clones of PHPUnit's Git repository
(https://github.com/sebastianbergmann/phpunit/network/members) as forks.
It's merely
On Fri, 2011-08-12 at 12:29 +0100, Lester Caine wrote:
Actually the real question here is WHY create a fork on github at all? The
copy
you are working on LOCALLY is the fork that you are developing on? Much of
the
stuff on github and the other DVCS server sites is redundant? You only need
On 08/12/2011 07:38 AM, Kalle Sommer Nielsen wrote:
Normally not my cup of coffee entering a threat on which VCS we should
use, I honestly can't see why we didn't choose another over SVN when
we had a year long discussion about it. I remember Rasmus said that
when we change version control
2011/8/12 Sebastian Bergmann sebast...@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
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
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
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
On Fri, Aug 12, 2011 at 07:54, Kalle Sommer Nielsen ka...@php.net wrote:
2011/8/12 Sebastian Bergmann sebast...@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
Hi!
On 8/12/11 3:26 AM, Derick Rethans wrote:
But you can't call it PHP anymore due to the license, where as with a
DCVS with people having forks on publically accessible repositories,
everybody is basically violating the license.
Well, the license is something to think about, yes.
I share
Hi!
On 8/12/11 4:29 AM, Lester Caine wrote:
Actually the real question here is WHY create a fork on github at all? The copy
Pull requests, for one.
you are working on LOCALLY is the fork that you are developing on? Much of the
stuff on github and the other DVCS server sites is redundant?
Hi!
On 8/12/11 5:14 AM, Lester Caine wrote:
But that is the point ... if everybody has their own published 'experimental
feature' repos, syncing those bits we are playing with looks like a nightmare?
Of course. Unless you are using modern tools to manage this, like, hmmm,
github? ;)
--
Hi!
On 8/12/11 4:38 AM, Kalle Sommer Nielsen wrote:
I can't see why we can't offer mirrors that can be written to and
synced for people who absolutely cannot work inside a centralized
system like our current model. I would really, really hate to
You don't want to deal with syncing writable
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
Hi!
On 8/12/11 11:47 AM, Lester Caine wrote:
Pull requests, for one.
Push/Pull from local copy?
No, no. Pull requests and push/pull are very different things. Having
people just push whatever they like whenever they like into main code is
what we have now, and it's not really the best way
On 12 August 2011 20:02, Stas Malyshev smalys...@sugarcrm.com wrote:
Branches are different things than github forks, for different purposes.
Branch is a project, fork is a workspace. You can have multiple people work
on a project, using multiple workspaces.
And today I learned something.
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.
On Fri, Aug 12, 2011 at 3:01 PM, Lester Caine les...@lsces.co.uk wrote:
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
Hi!
On 8/12/11 3:01 PM, Lester Caine 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 ...
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 ...
On Sat, Aug 13, 2011 at 12:26 AM, Lester Caine les...@lsces.co.uk wrote:
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
On 08.08.2011 08:58, Ryan McCue wrote:
Kiall Mac Innes wrote:
Later on in the doc, you go into detail about submodules, and CRLF - LF
support in both Git and Hg.
To be fair, submodules don't work exactly the same. Unlike
svn:externals, which are linked to a repository, submodules are linked
Joey Smith wrote:
In fact, if you're using git as your DVCS, there's even a bunch of
porcelain [2] to make it easier to manage your trees.
Side note: For anyone not familiar with Git terminology: plumbing is
all the commands that alter the repository, while porcelain are tools
built on top of
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.
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
Stas Malyshev wrote:
On 8/7/11 5:46 PM, Lester Caine wrote:
Use git.
And stick two fingers up at the windows developer base ;)
What's the problem with git and windows? I understand there is a good
GUI-installable package with all needed and everything works just fine -
at least I know people
On 08/08/11 07:37, Richard Riley wrote:
David Soria Parra d...@php.net writes:
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As somebody that have seen reasonably big project switch from SVN to git
and worked quite actively with git since then, I think describing my
David Muir wrote:
I'm only reverting a single commit rather
than having to weed through the tree to find all the commits that need
to be reversed. And if I'm doing it wrong™, please let me know off
list how I can improve things.
I think this a general problem with DVCS method of working? At
On Sun, Aug 7, 2011 at 10:50 PM, David Soria Parra d...@php.net wrote:
Hi Internals,
Distributed Version Control Systems (DVCS) getting more and more
popular. In fact they have been discussed within the PHP community and
on Internals a few times. It came to my attention that more and more
David Muir wrote:
John Szakmeister, who is a Subversion developer himself, has a good
comparison of svn, hg, bzr and git:
http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/
Long story short, his company went with git.
Makes good reading ... many other comparisons
On Sun, 2011-08-07 at 16:50 -0400, David Soria Parra wrote:
I was asked to put together a RFC, and so here we are. I've created
an initial draft. It is mostly based on the very good Python PEP-0374.
It compares Git and Mercurial.
https://wiki.php.net/rfc/dvcs
Two comments:
* It
Hi!
On 8/8/11 9:34 AM, Johannes Schlüter wrote:
* It is said that the preferred way to get a patch from one branch
to another is by doing a merge operation in the VCS. Depending
on the timing we will most likely end up with two (trunk + 5.4)
or, more likely,
On 09/08/11 01:07, Lester Caine wrote:
David Muir wrote:
John Szakmeister, who is a Subversion developer himself, has a good
comparison of svn, hg, bzr and git:
http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/
Long story short, his company went with git.
Hi, very glad this topic has resurfaced and I honesly think using a DVCS
will be a game-changer for PHP. Just wanted to drop a couple of answers I've
dedicated some time in at SE, several diagrams, to-point explanations and
references that might be of uso to clear out introductory topics.
On 08/07/2011 04:24 PM, Stas Malyshev wrote:
Hi!
As somebody that have seen reasonably big project switch from SVN to
git and worked quite actively with git since then, I think describing
my experience might be useful for those that never tried it.
1. git is much better than svn especially
On Sun, Aug 07, 2011 at 04:50:55PM -0400, David Soria Parra wrote:
Hi Internals,
NOTE: this is not the place for any religiouise discussion about git vs
mercurial whatsover. if you have nothing else to add than hg is $***
anyway or think hosting platform XY will solve all our problems
On Mon, Aug 8, 2011 at 6:52 PM, Larry Garfield la...@garfieldtech.com wrote:
A previous poster claimed that a DVCS would lead to confusion as to what the
canonical repository was. That is, in my experience, a common fear of
someone who has not used a DVCS in production.
Disclaimer: I haven't
On 7 August 2011 21:50, David Soria Parra d...@php.net wrote:
Hi Internals,
Distributed Version Control Systems (DVCS) getting more and more
popular. In fact they have been discussed within the PHP community and
on Internals a few times. It came to my attention that more and more
people like
On 2011-08-07, Richard Quadling rquadl...@gmail.com wrote:
I feel I have a major objection to using a DVCS for PHP.
Currently, a single source provides a sense of authority. If bad code
is committed, it will be quickly dealt with. If good code is
incomplete it may be withdrawn or fixed. In
On Sun, 2011-08-07 at 22:13 +0100, Richard Quadling wrote:
So, when someone like me comes along, someone capable of building the
code and playing with it at a very minor level, I can be sure that if
things don't work, it is probably me that's broke it and that I can
rely on the branch to
Hi!
As somebody that have seen reasonably big project switch from SVN to git
and worked quite actively with git since then, I think describing my
experience might be useful for those that never tried it.
1. git is much better than svn especially as applied to complex projects
with multiple
Hi!
On 8/7/11 2:13 PM, Richard Quadling wrote:
There will be (not might be, but will be), multiple, and potentially
conflicting/incompatible, versions available. Which do I choose? If
everyone is capable of forking PHP, which is the official one? In the
event of a single official repo, then why
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As somebody that have seen reasonably big project switch from SVN to git
and worked quite actively with git since then, I think describing my
experience might be useful for those that never tried it.
1. git is much better than
David Soria Parra d...@php.net writes:
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As somebody that have seen reasonably big project switch from SVN to git
and worked quite actively with git since then, I think describing my
experience might be useful for those that
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
Hi David,
Think I may have spotted a mistake in the RFC:
Decentralized version control system have some drawbacks:
*... Snip .. *
no svn:externals, no svn:eol-style
Later on in the doc, you go into detail about submodules, and CRLF - LF
support in both Git and Hg.
Thanks,
Kiall
On Sun,
On 08/07/2011 11:37 PM, Richard Riley wrote:
David Soria Parra d...@php.net writes:
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
[...]
Its really simple.
Use git.
It works, is fast and is rapidly becoming the industry standard. Do not
sue something for moral grounds
On Mon, Aug 8, 2011 at 1:35 AM, Stefan Neufeind neufe...@php.net wrote:
On 08/07/2011 11:37 PM, Richard Riley wrote:
David Soria Parra d...@php.net writes:
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
[...]
Its really simple.
Use git.
It works, is fast and is rapidly
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
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
On 08/08/2011 01:44 AM, Ferenc Kovacs wrote:
On Mon, Aug 8, 2011 at 1:35 AM, Stefan Neufeind neufe...@php.net wrote:
On 08/07/2011 11:37 PM, Richard Riley wrote:
David Soria Parra d...@php.net writes:
On 2011-08-07, Stas Malyshev smalys...@sugarcrm.com wrote:
[...]
Its really simple.
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
Hi!
On 8/7/11 5:46 PM, Lester Caine wrote:
Use git.
And stick two fingers up at the windows developer base ;)
What's the problem with git and windows? I understand there is a good
GUI-installable package with all needed and everything works just fine -
at least I know people using it
On Mon, Aug 8, 2011 at 1:46 AM, Lester Caine les...@lsces.co.uk wrote:
Richard Riley wrote:
Its really simple.
Use git.
And stick two fingers up at the windows developer base ;)
I admit I don't use windows often, but when I do, TortoiseGit has always
worked fine for me!
It works, is
75 matches
Mail list logo
