hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.
I think git could be a great help, maintaining multiple branches will
be easier. It will also be very useful to develop new complex features
requiring a longer development period. SVN works fine but merging is
very limited and buggy, maintaining a branch while syncing changes
from trunk/other branches is a very frustrating experiences.
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
[snip]
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
You might recall several conversations on this during the period
where Gwynne was migrating us from CVS to SVN in 2008/09. Two two
threads that stand out most in my mind were Rasmus' thoughts on the
matter[1] and David Soria Parra actually working toward using git ---
or at least git-svn[2]. There were several other threads on the
subject as well, so unless opinions have changed, you may already have
some folks in your corner.
^1: http://news.php.net/svn.migration/255
^2: http://news.php.net/php.internals/44942
--
</Daniel P. Brown
hi,
[snip]
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.You might recall several conversations on this during the periodwhere Gwynne was migrating us from CVS to SVN in 2008/09. Two two
threads that stand out most in my mind were Rasmus' thoughts on the
matter[1] and David Soria Parra actually working toward using git ---
or at least git-svn[2]. There were several other threads on the
subject as well, so unless opinions have changed, you may already have
some folks in your corner.^1: http://news.php.net/svn.migration/255 ^2: http://news.php.net/php.internals/44942
FWIW, the KDE project migrated from CVS to SVN a few years ago and is now in
the process of migrating to Git following numerous KDE projects moving to
Github of their own accord. They're doing a piece-meal approach with projects
migrating bit by bit. I believe they are hosting their own Git setup but I'm
not certain of that.
The Drupal project skipped SVN entirely and is currently in the process of
migrating our entire infrastructure from CVS to Git, which we will be self-
hosting. Numerous Drupal projects were already migrating to Github and we
decided, basically, "CVS sucks and people are voting with their feet for Git".
We opted to setup our own Git infrastructure rather than use GitHub's because
our development toolchain is very tightly coupled with our version control
system and issue queue history, and we wanted to retain that. We couldn't do
that on Github, but building our own we could. A nice side-effect of this
process (in progress as we speak) is a number of more generic tools (many
Drupal-based, I grant) for version control handling, particularly Git.
By the time we're done (hopefully late Q1 2011) we should have a number of
people who know a disturbing amount about Git and Git-PHP, and I suspect many
could be coaxed to at least provide advise and consultation if not actual
labor. (I am not one of those people so I can't speak for them, but I would
certainly be willing to poke and prod people into offering what help they can.
<g>)
Having been an SVN fan for a long time, I must say I am really liking
working with Git for the past year or so on various projects.
--Larry Garfield
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
I would be +1 on this, where 1 is the biggest 1 possible without it
becoming 2. :)
git-svn is a reasonable alternative for smaller repositories and
projects (I use it at work on a daily basis to deal with older
projects that we haven't migrated to git), but the PHP repository is
difficult to use effectively with it, since it (in my experience, at
least) requires a checkout of every revision for proper handling of
branches and tags. git-svn also imposes some restrictions on developer
workflow which aren't insurmountable, but do limit what you can do
relative to a real git repository.
So, in short, I'd love to see us move to git.
Adam
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
The main reasons we moved to SVN and not Git include:
- Less of a learning curve, because SVN is like CVS
- Most of the CVS->SVN work was already finished
- A few old timers didn't want us using Git
- We aren't sure how the authentication/karma system would work
Most people wanted (and still want) to move to Git, but moving to SVN was a simpler process. Any proposal towards Git should include how it'd work. Also, Github (yes or no) is another part of this.
Regards,
Philip
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.The main reasons we moved to SVN and not Git include:
- Less of a learning curve, because SVN is like CVS
- Most of the CVS->SVN work was already finished
- A few old timers didn't want us using Git
- We aren't sure how the authentication/karma system would work
Most people wanted (and still want) to move to Git, but moving to SVN
was a simpler process. Any proposal towards Git should include how
it'd work. Also, Github (yes or no) is another part of this.
Git is not the only DVCS either! The others (mercurial, bazaar) should
also be looked at.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi!
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.
My personal experience is that git runs circles around svn when it comes
to merging and branching, etc. There's some learning curve but you can
get used to it in less than a month. However, there are a lot of
practical challenges (auth, etc.) that need to be solved.
I personally wouldn't mind using git but we need to find a brave soul
that would agree to figure out all the challenges. As for now, we
already have github mirror, so maybe private needs can be served by it...
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
However, there are a lot of
practical challenges (auth, etc.) that need to be solved.
I think one of the biggest issues is PHP extension handling. All ways
for moving extensions in/out while keeping history are annoying. Doing
all in sub-modules would be damn annoying ... that certainly needs
evaluation before a switch.
Other than that I really love git :-)
johannes
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, November 24, 2010 5:47 PM
To: PHP internals
Subject: [PHP-DEV] git anyone?hi,
We have moved not too long ago and for what I see it gave some opportunities
to many of us to see what are the other tools on the market, git and github in
particular. I think 99% of the active developers here are on github or use git in
one way or another.I think git could be a great help, maintaining multiple branches will be easier. It
will also be very useful to develop new complex features requiring a longer
development period. SVN works fine but merging is very limited and buggy,
maintaining a branch while syncing changes from trunk/other branches is a
very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to get a
feeling/poll about git usage.
I personally doubt moving will have a material positive impact on the project. I wouldn't particularly mind if all the issues were addressed but I wouldn't hold my breath that it will be game changing. It may be better to invest the effort elsewhere.
Andi
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, November 24, 2010 5:47 PM
To: PHP internals
Subject: [PHP-DEV] git anyone?We have moved not too long ago and for what I see it gave some opportunities
to many of us to see what are the other tools on the market, git and github in
particular. I think 99% of the active developers here are on github or use git in
one way or another.I think git could be a great help, maintaining multiple branches will be easier. It
will also be very useful to develop new complex features requiring a longer
development period. SVN works fine but merging is very limited and buggy,
maintaining a branch while syncing changes from trunk/other branches is a
very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to get a
feeling/poll about git usage.I personally doubt moving will have a material positive impact on the
project. I wouldn't particularly mind if all the issues were addressed
but I wouldn't hold my breath that it will be game changing. It may be
better to invest the effort elsewhere.
I disagree here, actually. It's much easier to handle feature isolation
using git, as you can do these in separate branches -- perhaps not even
on the canonical repo! -- and later merge them in when they are ready.
Additionally, keeping multiple branches up-to-date is much, much
simpler. With ZF, I've found that merging in even months worth of
changes from the ZF1 trunk to ZF2 master is often a matter of hours;
with SVN, this process was so daunting, we simply wouldn't do it in
favor of creating new branches and starting over.
--
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
Pierre Joye wrote:
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that the git
cygwin install destroys! And as yet there is no consensus on getting it working
cross platform in things like Eclipse.
At least hg works out of the box on both linux and windows, but like git THAT
does not properly support sub-repo's and makes managing nice modularly
constructed projects like PHP almost impossible.
Trying to work with projects that write modular PHP code in either git or hg is
simply not currently practical ... especially when half of your user base is
still tied to 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
Pierre Joye wrote:
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.Have you used git on Windows Pierre ... It is a joke!
I'm pretty sure, that Pierre uses windows on his desktop. :)
Tyrael
2010/11/25 Lester Caine lester@lsces.co.uk:
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that the git
cygwin install destroys! And as yet there is no consensus on getting it
working cross platform in things like Eclipse.At least hg works out of the box on both linux and windows, but like git
THAT does not properly support sub-repo's and makes managing nice modularly
constructed projects like PHP almost impossible.Trying to work with projects that write modular PHP code in either git or hg
is simply not currently practical ... especially when half of your user base
is still tied to windows!
Git on Windows problems belong to the past since a while now:
- mSysGit
- TortoiseGit
Patrick ALLAERT wrote:
2010/11/25 Lester Cainelester@lsces.co.uk:
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that the git
cygwin install destroys! And as yet there is no consensus on getting it
working cross platform in things like Eclipse.At least hg works out of the box on both linux and windows, but like git
THAT does not properly support sub-repo's and makes managing nice modularly
constructed projects like PHP almost impossible.Trying to work with projects that write modular PHP code in either git or hg
is simply not currently practical ... especially when half of your user base
is still tied to windows!Git on Windows problems belong to the past since a while now:
- mSysGit
Provide you don't use cygwin ALREADY on your machine !!!
Install mSysGit and existing packages stop working ...
- TortoiseGit
TortoiseHg does it RIGHT and works on both Linux and Windows. TortoiseGit does
not work on Linux ...
Personally I run hg since I need cross platform capability for my customers, and
hggit quite happily links to github but all of this has to be managed outside
Eclipse since none of those tools work reliably.
And we STILL have the problem of handling modular projects since neither do
'sub-repo' reliably. This area seems to be in a similar state of chaos to PHP
with different factions all pushing their own agendas. Both git and hg are
targeting compiled applications and ignore handing scripted applications like
php, python, ruby and the like. 'You fix the problems when you build a project'
simply does not work when you do not have anything to build! So while it may
work for building PHP as a single program, a packaged distribution is a
different matter.
--
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
Patrick ALLAERT wrote:
2010/11/25 Lester Cainelester@lsces.co.uk:
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that
the git
cygwin install destroys! And as yet there is no consensus on getting it
working cross platform in things like Eclipse.At least hg works out of the box on both linux and windows, but like git
THAT does not properly support sub-repo's and makes managing nice
modularly
constructed projects like PHP almost impossible.Trying to work with projects that write modular PHP code in either
git or hg
is simply not currently practical ... especially when half of your
user base
is still tied to windows!Git on Windows problems belong to the past since a while now:
- mSysGit
Provide you don't use cygwin ALREADY on your machine !!!
Install mSysGit and existing packages stop working ...
While I don't use Windows, I do know that msysgit keeps things separate
and shouldn't clobber your cygwin setup. Perhaps you have an issue with
your path?
The state of Git on Windows is, yes, far from perfect, but certainly
improving. A quick search yields up some nice looking tools for Git on
Windows:
http://www.makeuseof.com/tag/5-windows-git-clients-git-job/
SmartGit looks pretty good (non-commercial use).
Git on Windows is not 100% friendly, but is workable. We have people
using it everyday at work here.
- TortoiseGit
TortoiseHg does it RIGHT and works on both Linux and Windows.
TortoiseGit does not work on Linux ...
I use Linux and quite frankly I couldn't give a damn about things like
Tortoise*. Such tools are nice enough for Windows where command prompt
is so desperately useless, but they are no substitute for a real
understanding of the command line interface of the SCM tool.
I have a decent "command prompt" in Linux and it is a hell of a lot
quicker (and, I would say, easier) to use.
In short - I'm not sure why you're trying to slag off Git because
TortoiseGit is no good for Linux. What is wrong with git-gui, gitk or gitg?
Personally I run hg since I need cross platform capability for my
customers, and hggit quite happily links to github but all of this has
to be managed outside Eclipse since none of those tools work reliably.And we STILL have the problem of handling modular projects since neither
do 'sub-repo' reliably. This area seems to be in a similar state of
chaos to PHP with different factions all pushing their own agendas. Both
git and hg are targeting compiled applications and ignore handing
scripted applications like php, python, ruby and the like. 'You fix the
problems when you build a project' simply does not work when you do not
have anything to build! So while it may work for building PHP as a
single program, a packaged distribution is a different matter.
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breakage by feature removal...
Nick Pope wrote:
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breakage by feature removal...
I have been using Eclipse for development for several years, and PHPEclipse does
everything I need. CVS and SVN simply work ... fully integrated ... and
BeyondCompare handles all of the 'merge' problems that a simple update or manual
merge has trouble with. For that reason I have never had a problem with 'merging'.
Eclipse works transparently in linux and windows ... it is the reason that I
started using it in the first place. I do not have to think 'linux ... commmand
line'/'windows ... need something else'
Neither GIT nor HG integration works with Eclipse so I have to drop outside
Eclipse to handle picking up changes from github, and for HG, the graphics tools
simply work transparently. BUT in reality the broken Eclipse in integration
needs to be repaired if these projects are to really support a replacement of
CVS and SVN.
I have wasted weeks of possible real coding time trying to get git working for
ME and I'm not going to spend any more until it is available as a working
plugin for Eclipse. I AM using HG but simply as it was the only way to remain in
touch with my main commercial activities since those developers forced a change
to github.
I would strongly agree with the statement that CVS is ideal for PHP since that
at least has a working package management system which has worked for years.
Managing merges is NOT a problem if you are used to tools which fix the problem,
in much the same way as third party plugins already try to do in git and hg!
Currently importing a CVS project into either git or hg creates an essentially
unusable mess since the package management is no longer avialable. How do you
combine a 200 package CVS project which gets mapped to 200 repos to create a
single distributable project in ANY DVCS system?
--
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
Nick Pope wrote:
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breakage by feature removal...I have been using Eclipse for development for several years, and
PHPEclipse does everything I need. CVS and SVN simply work ... fully
integrated ... and BeyondCompare handles all of the 'merge' problems
that a simple update or manual merge has trouble with. For that reason I
have never had a problem with 'merging'.
I wasn't really referring to the diff tools like BeyondCompare. I was
referring to having a SCM tool that does proper branching and merging.
Git does, SVN really doesn't. Git is incredibly flexible when it
comes to branching. It is also space efficient which is useful on large
projects - a branch isn't a complete copy. Git is faster/distributed -
doesn't require access to the remote repository to perform a diff/merge
- useful if you are without network access. And generally operations
are quick because they occur on blobs that contain just the changes
rather than the entire source tree.
Eclipse works transparently in linux and windows ... it is the reason
that I started using it in the first place. I do not have to think
'linux ... commmand line'/'windows ... need something else'
Fair enough regarding eclipse... I wasn't slamming it, I just don't use
it. And I don't really find that lack of SCM integration in IDE is the
end of the world.
But if you are using msysgit which uses a bash shell for running command
line Git... You don't have to think any different.
Neither GIT nor HG integration works with Eclipse so I have to drop
outside Eclipse to handle picking up changes from github, and for HG,
the graphics tools simply work transparently. BUT in reality the broken
Eclipse in integration needs to be repaired if these projects are to
really support a replacement of CVS and SVN.
I really couldn't make sense of this. Also - did you actually read my
last reply? The link I sent you linked to this:
http://www.eclipse.org/egit/
I've never used it. I can't vouch for it. But if that isn't some form
of integration, I don't know what is.
I have wasted weeks of possible real coding time trying to get git
working for ME and I'm not going to spend any more until it is
available as a working plugin for Eclipse. I AM using HG but simply as
it was the only way to remain in touch with my main commercial
activities since those developers forced a change to github.
Fair enough. I just can't really see that there is that much of a
problem with Git. It has rough edges on Windows as I've said in my last
reply. Again - there is a plugin.
I would strongly agree with the statement that CVS is ideal for PHP
since that at least has a working package management system which has
worked for years. Managing merges is NOT a problem if you are used to
tools which fix the problem, in much the same way as third party plugins
already try to do in git and hg! Currently importing a CVS project into
either git or hg creates an essentially unusable mess since the package
management is no longer avialable. How do you combine a 200 package CVS
project which gets mapped to 200 repos to create a single distributable
project in ANY DVCS system?
Seriously? CVS is painful. Back when I first looked into SCM I brushed
on it and skipped straight to SVN.
"Managing merges is NOT a problem if you are used to tools which fix the
problem..."
That goes without saying for pretty much any SCM tool.
"...in much the same way as third party plugins already try to do in git
and hg!"
Third-party plugins?! That's news to me. I think you mean use of an
external program that already handles diffs/merges. Why reinvent the
wheel. And you were going on about "BeyondCompare". Would that not be
exactly the same.
"Currently importing a CVS project into either git or hg creates an
essentially unusable mess..."
In my opinion it was in a mess in the first place...
"...working package management system..."
I presume this is multiple projects in a single repository? Yes, Git
doesn't have that. Again - it just sounds like a mess to me. I've
never had to have a "package management system" in a SCM repository
myself before, so I guess I cannot comment too strongly on this.
However, submodules do work quite nicely. I won't pretend that they are
a perfect solution in every case because the are tied by commit. Anyone
who doesn't want the cruft can ignore them. The PHP repository could
probably do with some level of segmentation anyway - it is one giant
monolithic beast at the moment.
Nick Pope wrote:
I really couldn't make sense of this. Also - did you actually read my
last reply? The link I sent you linked to this:I've never used it. I can't vouch for it. But if that isn't some form of
integration, I don't know what is.
Please check fact before posting 'solutions' ...
egit does not ACTUALLY fully work hence the main reason it is still an
incubation project. The main problem is that jgit on which it is based does not
current support sub-repo, and as soon as there is a sub-repo in the target then
nothing works!
"...working package management system..."
I presume this is multiple projects in a single repository? Yes, Git
doesn't have that. Again - it just sounds like a mess to me. I've never
had to have a "package management system" in a SCM repository myself
before, so I guess I cannot comment too strongly on this.However, submodules do work quite nicely. I won't pretend that they are
a perfect solution in every case because the are tied by commit. Anyone
who doesn't want the cruft can ignore them. The PHP repository could
probably do with some level of segmentation anyway - it is one giant
monolithic beast at the moment.
sub-repo STILL needs work to allow a SINGLE download of a clone complex repo.
PHP is a number of packages which combine to provide a single distribution, and
packages can be added as required. It is not a single monolithic beast. Either
the whole modular setup is imported into a single git repo, or each package has
it's own repo. It is THEN that the holes in sub-repo management become a problem!
( And installing msysgit broke ssh access to my customer sites from the windows
box. A couple of days working on fixing that produced no solution, while simply
un-installing it restored all of the broken functionality. It was a few months
ago, but I don't believe anything ha changed so I will not be wasting time on it
until someone says that msysgit is now working with an existing putty/secure key
setup ... What I have has worked for years and git broke it! )
--
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
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no solution,
while simply un-installing it restored all of the broken functionality. It
was a few months ago, but I don't believe anything ha changed so I will not
be wasting time on it until someone says that msysgit is now working with an
existing putty/secure key setup ... What I have has worked for years and git
broke it! )
As this is off topic, the question is about using git for php.net, not
really about how to do break a windows setup :) I use cygwin, msys,
msysgit (separate install) and putty on the same machines, without any
special issues.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no solution,
while simply un-installing it restored all of the broken functionality. It
was a few months ago, but I don't believe anything ha changed so I will not
be wasting time on it until someone says that msysgit is now working with an
existing putty/secure key setup ... What I have has worked for years and git
broke it! )As this is off topic, the question is about using git for php.net, not
really about how to do break a windows setup :) I use cygwin, msys,
msysgit (separate install) and putty on the same machines, without any
special issues.Cheers,
Agreed. Sorry. Was just trying to say that I really don't think that
support for Windows is an issue.
Nick Pope wrote:
I really couldn't make sense of this. Also - did you actually read my
last reply? The link I sent you linked to this:I've never used it. I can't vouch for it. But if that isn't some form of
integration, I don't know what is.Please check fact before posting 'solutions' ...
egit does not ACTUALLY fully work hence the main reason it is still an
incubation project. The main problem is that jgit on which it is based
does not current support sub-repo, and as soon as there is a sub-repo in
the target then nothing works!
Granted it doesn't fully work. You said "Neither GIT nor HG
integration works with Eclipse..." and I disagreed. You just told me
that it doesn't fully work. Thus it must do to some extent...
What you mean is that it currently doesn't work for you. "... and I'm
not going to spend any more until it is available as a working plugin
for Eclipse." That is fine - I'd just use the command line and be done
with it to be honest. I never found even the SVN eclipse integration to
be all that wonderful either. Each to their own.
"...working package management system..."
I presume this is multiple projects in a single repository? Yes, Git
doesn't have that. Again - it just sounds like a mess to me. I've never
had to have a "package management system" in a SCM repository myself
before, so I guess I cannot comment too strongly on this.However, submodules do work quite nicely. I won't pretend that they are
a perfect solution in every case because the are tied by commit. Anyone
who doesn't want the cruft can ignore them. The PHP repository could
probably do with some level of segmentation anyway - it is one giant
monolithic beast at the moment.sub-repo STILL needs work to allow a SINGLE download of a clone complex
repo. PHP is a number of packages which combine to provide a single
distribution, and packages can be added as required. It is not a single
monolithic beast. Either the whole modular setup is imported into a
single git repo, or each package has it's own repo. It is THEN that the
holes in sub-repo management become a problem!
I said that the SVN repository is just a single glob of everything: PHP,
PECL stuff, etc...
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no
solution, while simply un-installing it restored all of the broken
functionality. It was a few months ago, but I don't believe anything ha
changed so I will not be wasting time on it until someone says that
msysgit is now working with an existing putty/secure key setup ... What
I have has worked for years and git broke it! )
Uhh... I can tell you now that msysgit and putty are fine together...
With public keys. Because my colleagues use it every day.
As much as i might not have enough Karma to vote, being only involved
in tests, but i think git would be a great fit.
I agree with Phillip that we need to address the issues mentioned
before if we want to move over, but our community includes guys like
Travis Swicegood, who quite literally wrote the book on Git, i'm sure
we can count on his help to aid us in sorting those out.
I'm a +1 if we have also docs and usage examples to help the learning
curve of git beginners.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
The DVCS migration path would not have to be as radical as the path
from cvs to svn. A single section of the overall svn repoistory can
be migrated to a DVCS. This pilot repo would serve two purposes:
determine if that DVCS is the correct choice and allow for a more
gradual learning curve.
Python is in the process of doing this with Mercurial:
http://www.python.org/dev/peps/pep-0374/ - PEP 374: On switching to a DVCS
http://www.python.org/dev/peps/pep-0385/ - PEP 385: Migrating from svn
to Mercurial
There was talk of other alternatives to a DVCS too. Those should be
considered fully as well.
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
Herman Radtke wrote:
The DVCS migration path would not have to be as radical as the path
from cvs to svn. A single section of the overall svn repoistory can
be migrated to a DVCS. This pilot repo would serve two purposes:
determine if that DVCS is the correct choice and allow for a more
gradual learning curve.Python is in the process of doing this with Mercurial:
http://www.python.org/dev/peps/pep-0374/ - PEP 374: On switching to a DVCS
http://www.python.org/dev/peps/pep-0385/ - PEP 385: Migrating from svn
to MercurialThere was talk of other alternatives to a DVCS too. Those should be
considered fully as well.
While part of the reasoning behind going with Hg there was to do with the fact
that Hg is heavily python based, it is useful to note that the secondary reason
was the poor windows support, and apparent LACK of interest in git that swung
the decision hg's way.
At the end of the day however it probably has nothing to do with which DVCS is
used for master copies. The interoperability now available does mean that we can
safely ignore any 'choice' and simply use our own preference locally :) It will
be the management of processes which are the main problem, something that is
still outstanding anyway currently ...
--
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
At the end of the day however it probably has nothing to do with which DVCS is
used for master copies. The interoperability now available does mean that we can
safely ignore any 'choice' and simply use our own preference locally :) It will
be the management of processes which are the main problem, something that is
still outstanding anyway currently ...
Agreed that most of them are pretty interoperable at this point.
** DISCLAIMER: I am an employee of Canonical, owners of Launchpad **
May I suggest bzr+launchpad as another alternative. MySQL has
successfully migrated, and it would offer some real benefits to the
process management.
- Release and Milestone Management for bugs and specs (Blueprints)
- Blueprints tied to milestones/releases (Blueprints == RFC's)
- Powerful web based merge proposal management.
- Branch aware bug management (bzr commit --fixes lp:1234567 && bzr push
automatically attaches the branch to the bug)
I've not used git or hg much at all, but bzr has always satisfied my
needs for DVCS, and has recently gotten much faster and more space
efficient than it was in the past.
I've not used git or hg much at all, but bzr has always satisfied my
needs for DVCS, and has recently gotten much faster and more space
efficient than it was in the past.
Sorry, but I think bzr is not a good fit. It's numerous changes to the
repository format make it impossible to use. It's either slow if you use an old
version, or it's incompatible with old clients, let's say on an old debian box.
So I think php.net is better of using mercurial or git, but if we put together
an RFC for a migration, I'll make sure bzr is covered as well in an evaluation.
David Soria Parra wrote:
I've not used git or hg much at all, but bzr has always satisfied my
needs for DVCS, and has recently gotten much faster and more space
efficient than it was in the past.Sorry, but I think bzr is not a good fit. It's numerous changes to the
repository format make it impossible to use. It's either slow if you use an old
version, or it's incompatible with old clients, let's say on an old debian box.So I think php.net is better of using mercurial or git, but if we put together
an RFC for a migration, I'll make sure bzr is covered as well in an evaluation.
Personally I would need a very good reason to add yet another DVCS to the mix
here! I've not found bzr as easy to link to from hg as git is. In fact I've not
actually got it to play at all as yet ... while hg does work into git with only
the problems of managing multiple repo's which is still work in progress on both
of them.
That said, bzr does seem to handle the multiple repo's in a more user friendly
manor? It is just a pity that there is NOT a single target solution for DVCS as
everybody is currently scurrying off to their own corners :( The barriers have
already been drawn rather then there being concensus on some sort of standard.
--
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
I've not used git or hg much at all, but bzr has always satisfied my
needs for DVCS, and has recently gotten much faster and more space
efficient than it was in the past.
Sorry, but I think bzr is not a good fit. It's numerous changes to the
repository format make it impossible to use. It's either slow if you use an old
version, or it's incompatible with old clients, let's say on an old debian box.So I think php.net is better of using mercurial or git, but if we put together
an RFC for a migration, I'll make sure bzr is covered as well in an evaluation.
Personally I would need a very good reason to add yet another DVCS to the mix here! I've not found bzr as easy to link to from hg as git is. In fact I've not actually got it to play at all as yet ... while hg does work into git with only the problems of managing multiple repo's which is still work in progress on both of them.That said, bzr does seem to handle the multiple repo's in a more user friendly manor? It is just a pity that there is NOT a single target solution for DVCS as everybody is currently scurrying off to their own corners :( The barriers have already been drawn rather then there being concensus on some sort of standard.
I think it's high time I tossed in my 1.682¥(JPY) (according to current exchange rates)...
I've been out of the PHP dev community for some months now, so anything I say has to be taken with a grain of salt; I simply don't have the time right now to catch up in any detail on the current state of affairs.
That in mind, I was already disgusted with SVN by the time the move to it was finished. At the risk of drawing a bit of fire, I have to say I agree with Linus Torvalds' attitude about it, when he said (search "Linus Torvalds subversion" on Google for the reference) that it was pointless and that CVS couldn't be done right.
SVN ditched things CVS had that should've been kept. Sub-repo management (modules) and module merging/aliasing are the two I fought most with during the migration; externals were a BAD patch on the problem! SVN was trying to "do CVS right", but that simply doesn't hold together in the modern software development world. Centralized servers by themselves are an old model. Simple, but old. That's why DVCSs exist in the first place!
So yes, I think PHP needs to move past Subversion, which is being constantly held back by a model that's just too limited. The branching/merging nightmare seals the coffin, as far as I'm concerned.
Which DVCS do I think is best?
Git is the massive favorite out there at the moment, according to my Googling. I myself have never been able to fully get my head around it; someone said earlier in the thread that it's "a swiss army knife with a boom button", a sentiment I tend to agree with. Still, someone else also correctly said that the huge majority of devs in PHP right now do use it, and that can't be ignored. It is my observation that the Windows issues have been largely solved in more recent times. GitHub itself (while I would prefer something we host ourselves), is pretty easy to use.
I don't know much about Mercurial, having never used it, so I can't comment much on it. The fact that it continues to be prevalent at all versus Git says something for it, but it falls down against the ubiquity argument, as a quick glance suggests to me that the learning curve would actually be a bit worse than Git's. Its Web interface makes me cringe.
Bazaar is -my- current favorite, as its commands tend to translate almost directly from SVN's and while a minority, it has a passionate following (largely thanks to Ubuntu and MySQL, I think). But it being my personal favorite doesn't mean much. I also find Launchpad a bit incomprehensible, and Bazaar being written in Python feels a little odd to me. Don't we rely enough already on competing languages? :) (Mercurial also suffers from this.)
I am not going to attempt any kind of conclusion based on technical merits (branching/merging ability, sub-repo support, etc.), as I don't know what the status of these features is, and even if I did, I no longer have enough knowledge of PHP's current state to apply the knowledge.
So, I have to base my thought on what the most people are going to have the least trouble working with, and that's Git, hands down. There are more than enough people around the community with the full knowledge necessary to undertake the migration with minimum fuss; it's been pointed out that the kind of massive manual balancing I had to do for CVS->SVN would be completely absent.
I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^;
-- Gwynne
On Tue, Nov 30, 2010 at 10:49 AM, Gwynne Raskind gwynne@darkrainfall.orgwrote:
I've not used git or hg much at all, but bzr has always satisfied my
needs for DVCS, and has recently gotten much faster and more space
efficient than it was in the past.
Sorry, but I think bzr is not a good fit. It's numerous changes to the
repository format make it impossible to use. It's either slow if you use
an old
version, or it's incompatible with old clients, let's say on an old
debian box.So I think php.net is better of using mercurial or git, but if we put
together
an RFC for a migration, I'll make sure bzr is covered as well in an
evaluation.
Personally I would need a very good reason to add yet another DVCS to the
mix here! I've not found bzr as easy to link to from hg as git is. In fact
I've not actually got it to play at all as yet ... while hg does work into
git with only the problems of managing multiple repo's which is still work
in progress on both of them.That said, bzr does seem to handle the multiple repo's in a more user
friendly manor? It is just a pity that there is NOT a single target solution
for DVCS as everybody is currently scurrying off to their own corners :( The
barriers have already been drawn rather then there being concensus on some
sort of standard.I think it's high time I tossed in my 1.682¥(JPY) (according to current
exchange rates)...I've been out of the PHP dev community for some months now, so anything I
say has to be taken with a grain of salt; I simply don't have the time right
now to catch up in any detail on the current state of affairs.That in mind, I was already disgusted with SVN by the time the move to it
was finished. At the risk of drawing a bit of fire, I have to say I agree
with Linus Torvalds' attitude about it, when he said (search "Linus Torvalds
subversion" on Google for the reference) that it was pointless and that CVS
couldn't be done right.SVN ditched things CVS had that should've been kept. Sub-repo management
(modules) and module merging/aliasing are the two I fought most with during
the migration; externals were a BAD patch on the problem! SVN was trying to
"do CVS right", but that simply doesn't hold together in the modern software
development world. Centralized servers by themselves are an old model.
Simple, but old. That's why DVCSs exist in the first place!So yes, I think PHP needs to move past Subversion, which is being
constantly held back by a model that's just too limited. The
branching/merging nightmare seals the coffin, as far as I'm concerned.Which DVCS do I think is best?
Git is the massive favorite out there at the moment, according to my
Googling. I myself have never been able to fully get my head around it;
someone said earlier in the thread that it's "a swiss army knife with a boom
button", a sentiment I tend to agree with. Still, someone else also
correctly said that the huge majority of devs in PHP right now do use it,
and that can't be ignored. It is my observation that the Windows issues have
been largely solved in more recent times. GitHub itself (while I would
prefer something we host ourselves), is pretty easy to use.I don't know much about Mercurial, having never used it, so I can't comment
much on it. The fact that it continues to be prevalent at all versus Git
says something for it, but it falls down against the ubiquity argument, as a
quick glance suggests to me that the learning curve would actually be a bit
worse than Git's. Its Web interface makes me cringe.Bazaar is -my- current favorite, as its commands tend to translate almost
directly from SVN's and while a minority, it has a passionate following
(largely thanks to Ubuntu and MySQL, I think). But it being my personal
favorite doesn't mean much. I also find Launchpad a bit incomprehensible,
and Bazaar being written in Python feels a little odd to me. Don't we rely
enough already on competing languages? :) (Mercurial also suffers from
this.)I am not going to attempt any kind of conclusion based on technical merits
(branching/merging ability, sub-repo support, etc.), as I don't know what
the status of these features is, and even if I did, I no longer have enough
knowledge of PHP's current state to apply the knowledge.So, I have to base my thought on what the most people are going to have the
least trouble working with, and that's Git, hands down. There are more than
enough people around the community with the full knowledge necessary to
undertake the migration with minimum fuss; it's been pointed out that the
kind of massive manual balancing I had to do for CVS->SVN would be
completely absent.I just wish I didn't have to also admit that Trac is a really great project
management system. Unless things have changed drastically since I was last
active, PHP still needs one. ^^;-- Gwynne
--
just a little comment on the last statement:
do you know about mtrack? it is a trac "clone" written in php by Wez
Tyrael
I just wish I didn't have to also admit that Trac is a really great project
management system. Unless things have changed drastically since I was last
active, PHP still needs one. ^^;
just a little comment on the last statement:
do you know about mtrack? it is a trac "clone" written in php by Wez
Googles.
Reads.
Well... dang. Go Wez!!
I like it :-). Thanks for the pointer! I'll have to look into that in more detail soon, it could prove very useful. And it looks a good bit better than Trac too ;-).
-- Gwynne
Gwynne Raskind wrote:
Googles.
Reads.
Well... dang. Go Wez!!
Magic .... just what I was looking for 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
Hi, I've never participated on the lists, but this was a topic I could just
not look away from.
My take on this is that it all boils down to the statistics of the
developers and contributors, as Gwynne said, there is really no much merit
on technical aspects of the tools... but rather how the community plans to
use other tools around it.
My preferred DVCS is mercurial due to its portability (no messing with bash
consoles in Windows, using it is the same for all platforms) and the fact
that I use Netbeans as my main IDE and it comes by default with the
mercurial plugin (the Netbeans project uses mercurial). I also like
mercurial because Bitbucket.org is comparable enough to github, and more
generous with its free accounts (free private repositories and unlimited
space). I also like git, but I stick with mercurial. I have never used
bazaar... and I have never used svn for team development, fortunately =).
Regards,
David
Gwynne Raskind wrote:
Googles.
Reads.
Well... dang. Go Wez!!Magic .... just what I was looking for as well.
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.
Thanks for the constructive replies,
Cheers,
Hi, I've never participated on the lists, but this was a topic I could just
not look away from.My take on this is that it all boils down to the statistics of the
developers and contributors, as Gwynne said, there is really no much merit
on technical aspects of the tools... but rather how the community plans to
use other tools around it.My preferred DVCS is mercurial due to its portability (no messing with bash
consoles in Windows, using it is the same for all platforms) and the fact
that I use Netbeans as my main IDE and it comes by default with the
mercurial plugin (the Netbeans project uses mercurial). I also like
mercurial because Bitbucket.org is comparable enough to github, and more
generous with its free accounts (free private repositories and unlimited
space). I also like git, but I stick with mercurial. I have never used
bazaar... and I have never used svn for team development, fortunately =).Regards,
David
Gwynne Raskind wrote:
Googles.
Reads.
Well... dang. Go Wez!!Magic .... just what I was looking for as well.
--
Lester Caine - G8HFLContact - 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--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.
I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular we need someone for BZR to put together a good
RFC. I'll probably help evaluating Git and Mercurial.
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular we need someone for BZR to put together a good
RFC. I'll probably help evaluating Git and Mercurial.
An evaluation requires a clear set of goals first. Like: Why change?
What is broken? What can be improved? What are existing requirements?
Once that is done one can start evaluating specific tools.
johannes
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular we need someone for BZR to put together a good
RFC. I'll probably help evaluating Git and Mercurial.An evaluation requires a clear set of goals first. Like: Why change?
What is broken? What can be improved? What are existing requirements?
Once that is done one can start evaluating specific tools.
yes, I'm aware of that, but it make sense to ask for people support
right during a discussion. So we can get together and discuss the goals.
johannes
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular we need someone for BZR to put together a good
RFC. I'll probably help evaluating Git and Mercurial.An evaluation requires a clear set of goals first. Like: Why change?
What is broken? What can be improved? What are existing requirements?
Once that is done one can start evaluating specific tools.
Instead of doing this, how about concentrate in actual work for the next release?
And IMO, there's nothing broken that needs fixing or changing to some DVCS since SVN works just fine..
--Jani
thanks for remember me the obvious questions, anything else to add or?
2010/12/1 Johannes Schlüter johannes@schlueters.de:
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular we need someone for BZR to put together a good
RFC. I'll probably help evaluating Git and Mercurial.An evaluation requires a clear set of goals first. Like: Why change?
What is broken? What can be improved? What are existing requirements?
Once that is done one can start evaluating specific tools.johannes
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
I was following this path to push the adoption of a DVCS for the Joomla
project and I started to create the required documentation to make an
informed argument and evaluation, I made some diagrams to make the case for
their need for good team development and workflows, feel free to borrow any
content/diagrams from here http://docs.joomla.org/Dvcs
If an RFC is started I'd love to help. I have experience with git and
mercurial.
http://docs.joomla.org/DvcsRegards,
David
2010/12/1 Johannes Schlüter johannes@schlueters.de
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.I think it would be good to have people willing to help out with
evaluating
certain DVCS. In particular we need someone for BZR to put together a
good
RFC. I'll probably help evaluating Git and Mercurial.An evaluation requires a clear set of goals first. Like: Why change?
What is broken? What can be improved? What are existing requirements?
Once that is done one can start evaluating specific tools.johannes
The Drupal project's decision making process for moving to Git is documented
extensively here:
http://groups.drupal.org/node/48818
Just another data point.
--Larry Garfield
Hi,
I was following this path to push the adoption of a DVCS for the Joomla
project and I started to create the required documentation to make an
informed argument and evaluation, I made some diagrams to make the case for
their need for good team development and workflows, feel free to borrow any
content/diagrams from here http://docs.joomla.org/DvcsIf an RFC is started I'd love to help. I have experience with git and
mercurial.http://docs.joomla.org/DvcsRegards,
David
Yet another one here: http://hginit.com/00.html
http://hginit.com/00.htmlThe title says it all: "Subversion re-education".
It is actualyy a somewhat neutral article even though the page is a
mercurial tutorial.
Regards,
David
On Thu, Dec 2, 2010 at 12:44 AM, Larry Garfield larry@garfieldtech.comwrote:
The Drupal project's decision making process for moving to Git is
documented
extensively here:http://groups.drupal.org/node/48818
Just another data point.
--Larry Garfield
Hi,
I was following this path to push the adoption of a DVCS for the Joomla
project and I started to create the required documentation to make an
informed argument and evaluation, I made some diagrams to make the case
for
their need for good team development and workflows, feel free to borrow
any
content/diagrams from here http://docs.joomla.org/DvcsIf an RFC is started I'd love to help. I have experience with git and
mercurial.http://docs.joomla.org/DvcsRegards,
David
dukeofgaming wrote:
Yet another one here:http://hginit.com/00.html
http://hginit.com/00.htmlThe title says it all: "Subversion re-education".
It is actualyy a somewhat neutral article even though the page is a
mercurial tutorial.
Actually this probably point up one of the fundamental differences between the
different ways of working.
'Most people work with Mercurial through the command line'
... fill in your own package ...
Personally I very rairly use any of these from the command line, since Eclipse
has fully integrated facilities. The statement 'it just works from the cammand
line' only applies if that is what you are still using, but even CVS I would
have to dig out the manual to use the command line.
Productivity wise, having to pull out of the IDE to do code management is the
main problem with switching from CVS/SVN to any of the alternatives, but the
main thing I can't understand is how people actually MANAGE with command line
when dealing with a large number of changes? A graphical facility is almost
essential when navigating around complex code trees and viewing diffs which are
more than a few dozen lines?
( Pierre this is probably one of the reasons I had so much trouble building PHP
on windows ... simply because I have used graphic IDE's since C++ Builder 1 days
and before :( Command line working is a somewhat different mind set ... and
prior to C++ I was working on hand coded machine code ... )
--
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
Its actually faster to use the command line when u have enough practice;
picture yourself merging branches or something more complicated, I think its
easier typing stuff as you think it than finding your way around a GUI,
command line reacts faster than a GUI too. I use the IDE integration though,
but not the shell integration, at all. I agree on visualizing repository
tree on the GUI though. In the end its up to each individual.
Regards,
David
dukeofgaming wrote:
Yet another one here:http://hginit.com/00.html
http://hginit.com/00.htmlThe title says it all: "Subversion
re-education".
It is actualyy a somewhat neutral article even though the page is a
mercurial tutorial.Actually this probably point up one of the fundamental differences between
the different ways of working.'Most people work with Mercurial through the command line'
... fill in your own package ...Personally I very rairly use any of these from the command line, since
Eclipse has fully integrated facilities. The statement 'it just works from
the cammand line' only applies if that is what you are still using, but even
CVS I would have to dig out the manual to use the command line.Productivity wise, having to pull out of the IDE to do code management is
the main problem with switching from CVS/SVN to any of the alternatives, but
the main thing I can't understand is how people actually MANAGE with command
line when dealing with a large number of changes? A graphical facility is
almost essential when navigating around complex code trees and viewing diffs
which are more than a few dozen lines?( Pierre this is probably one of the reasons I had so much trouble building
PHP on windows ... simply because I have used graphic IDE's since C++
Builder 1 days and before :( Command line working is a somewhat different
mind set ... and prior to C++ I was working on hand coded machine code ... )--
Lester Caine - G8HFLContact - 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
dukeofgaming wrote:
Its actually faster to use the command line when u have enough practice;
picture yourself merging branches or something more complicated, I think
its easier typing stuff as you think it than finding your way around a
GUI, command line reacts faster than a GUI too. I use the IDE
integration though, but not the shell integration, at all. I agree on
visualizing repository tree on the GUI though. In the end its up to each
individual.
This is the key here.
When working on PHP projects via CVS and SVN I get a view of all the files which
have changed in the IDE. I can then review those changes and only need to select
those which do not clash with my own local changes. I can also immediately see
committed changes that NEED to be rolled back because they DO clash with the
areas that I am maintaining! Simply automatically merging from the command line
does not work FOR ME.
DVCS in theory provides a nice way for me to manage my own builds of these
projects, but the black hole is now how the clash problems are handled as there
is no easy way to roll back a change that has broken something else. Adding the
complexity of multiple packages across several projects ... smarty, adodb and
the like, or building the internal extensions which use libraries from the likes
of apache, firebird ... in theory should be simplified by the use of a DVCS
approach, but the reality is that it is still very early days and while people
are running to a number of camps there needs to be a more tidy integration path
rather than the current diversity that has been created.
I think that what we actually need is a complete rethink of what the problems
are ... including managing the user projects rather than JUST raw source code
... and agree a level of operation rather than the current approach of slagging
off the paths that you do not agree with. Every package has problems and none of
them offer a single solution?
--
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
Such IDE integration exists for mercurial, both for Eclipse and Netbeans,
also at shell level.
I really don't get why you say there is no easy way to rollback changes,
because there is. I do manage package updates and installations through
SVN (e.g. updating symfony, doctrine), I just don't use SVN to work with
other people. I believe that managing packages and working with people
should not be regarded as the same thing when talking about versioning
systems.
I think the main and general drive of people for adopting a DVCS is just
that, better workflows, and fortunately, some of them have actually worried
about interoperability, meaning its possible to import files from other
(D)VCSs.
Regards,
David
dukeofgaming wrote:
Its actually faster to use the command line when u have enough practice;
picture yourself merging branches or something more complicated, I think
its easier typing stuff as you think it than finding your way around a
GUI, command line reacts faster than a GUI too. I use the IDE
integration though, but not the shell integration, at all. I agree on
visualizing repository tree on the GUI though. In the end its up to each
individual.This is the key here.
When working on PHP projects via CVS and SVN I get a view of all the files
which have changed in the IDE. I can then review those changes and only need
to select those which do not clash with my own local changes. I can also
immediately see committed changes that NEED to be rolled back because they
DO clash with the areas that I am maintaining! Simply automatically merging
from the command line does not work FOR ME.DVCS in theory provides a nice way for me to manage my own builds of these
projects, but the black hole is now how the clash problems are handled as
there is no easy way to roll back a change that has broken something else.
Adding the complexity of multiple packages across several projects ...
smarty, adodb and the like, or building the internal extensions which use
libraries from the likes of apache, firebird ... in theory should be
simplified by the use of a DVCS approach, but the reality is that it is
still very early days and while people are running to a number of camps
there needs to be a more tidy integration path rather than the current
diversity that has been created.I think that what we actually need is a complete rethink of what the
problems are ... including managing the user projects rather than JUST raw
source code ... and agree a level of operation rather than the current
approach of slagging off the paths that you do not agree with. Every package
has problems and none of them offer a single solution?--
Lester Caine - G8HFLContact - 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
dukeofgaming wrote:
Such IDE integration exists for mercurial, both for Eclipse and
Netbeans, also at shell level.
This has already been covered ... git and hg integration is only partially
functional. Git is a right pain in windows, while hg is at least functional
identically in both linux and windows. BUT sub-repo is an area that is not
currently supported in any of the integration tools and hg-git actually fails if
there is a git sub-repo. Keeping each extension of php in it's own sub-repo is
the obvious way of managing things, but is the very area that is not fully
functional. Building a single 'download' of a group of packages is not something
that can currently be handled, as the 'module' structure of CVS simply can't be
mapped. A single CVS repo becomes 200+ separate repo's in hg or git, and you
then need script files to manage things, which is fine for command line users,
but a problem for the IDE approach.
I really don't get why you say there is no easy way to rollback changes,
because there is. I do manage package updates and installations through
SVN (e.g. updating symfony, doctrine), I just don't use SVN to work with
other people. I believe that managing packages and working with people
should not be regarded as the same thing when talking about versioning
systems.
Again you are missing the point here. CVS/SVN works nicely for managing a master
code base. DVCS does not naturally support that, and this is a major area that
needs to be managed by any project switching so that you CAN manage a master
codebase. The problem I was trying to highlight was that with patches around a
number of distributed copies, managing a 'rollback' can be difficult if several
people have pushed around different paths, and currently the available tools do
not allow the same flexibility that has been provided for CVS/SVN for several
years.
I think the main and general drive of people for adopting a DVCS is just
that, better workflows, and fortunately, some of them have actually
worried about interoperability, meaning its possible to import files
from other (D)VCSs.
Again ... there is no 'natural' workflow so it becomes a lot more difficult to
cooperate. I still think that a 'master' of the CVS/SVN type may be preferable
rather than trying to manage that via a DVCS maze? All of the projects that have
published their research have indicated that there is not a simple answer and
that the goal posts are still moving on a weekly basis? hg has published
improvements to the sub-repo problem only this week, but the integration
packages still have to catch 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
Again you are missing the point here. CVS/SVN works nicely for managing
a master code base. DVCS does not naturally support that, and this is a
major area that needs to be managed by any project switching so that you
CAN manage a master codebase.
I used to think that; I had no idea how you had an authoritative repo
when everyone had a repo. Then I actually started working with Git, and
the answer became obvious: You agree on one. You agree on a particular
branch in a particular repo (eg, the one hosted on kernel.org /
drupal.org / php.net) is the canonical branch, possibly restrict who can
push to that (or not, but I think that would help PHP by having a
release manager named early who can merge micro-branches), and document it.
Git doesn't technologically force an answer on you; you get to define
one socially. That actually works surprisingly well in practice in a
functional project. (If PHP can't come to such an agreement in
practice, that's a social problem, not a tool problem.)
--Larry Garfield
TortoiseGit
So, I now have TortoiseCVS, TortoiseSVN and TortoiseGit. Gee! My
windows is slow enough ... now I'm pulling along 3 tortoises.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
2010/11/25 Pierre Joye pierre.php@gmail.com:
hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.I think git could be a great help, maintaining multiple branches will
be easier. It will also be very useful to develop new complex features
requiring a longer development period. SVN works fine but merging is
very limited and buggy, maintaining a branch while syncing changes
from trunk/other branches is a very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Definetely a big +1.
But you don't want us to be geeky early adopters, do you?
Let's wait everybody else did the svn->git migration before us like we
always did :)
hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.I think git could be a great help, maintaining multiple branches will
be easier. It will also be very useful to develop new complex features
requiring a longer development period. SVN works fine but merging is
very limited and buggy, maintaining a branch while syncing changes
from trunk/other branches is a very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.Cheers,
I liked the DVCS idea back when we switched to SVN and I still like it.
It is good to have the perspective of switching over to a DVCS in the future
if developers want to. But we need to make sure that a few topics are sorted
out before. In particular
-
Karma System
Although you can use DVCS in a centralized fashion they are much better when
it comes to the ..distributed.. part. We either need to change the way we develop
towards a more push/pull mechanism or implement the karma system. -
Easy Access
I don't think that's a big deal at all. Developers who can learn how to write
PEAR/PECL, PHP-SRC code probably know how to learn a tool. For the rest,
we successfully installed read-only Git->SVN bridges at phpBB when Nils Adermann
and I did their migration. -
Hosting
Rasmus was thinking about using github. -
Less Learning Curve
Ah, I think Git reached the masses and people become more and more able to deal with
Git. Anyway, still Git is a swiss army knife with a big red "boom" button on top of it
from time to time. -
A few old timers didn't want us using Git
They'll get over it.
If someone is interested in moving into the direction of using a DVCS, this is either
Git or Mercurial, I'm happy to help with evaluation and migration.
- David
- A few old timers didn't want us using Git
They'll get over it.
The great thing is... that git can work as an svn client or You can work
with svn client on a github git repo ( afair ? ) ;-)
- Krzysztof
I really like Git (much more than SVN actually) and I use it for all my projects,
but I doubt moving to Git would solve anything.
IMO even CVS was quite enough for our development model.
hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.I think git could be a great help, maintaining multiple branches will
be easier. It will also be very useful to develop new complex features
requiring a longer development period. SVN works fine but merging is
very limited and buggy, maintaining a branch while syncing changes
from trunk/other branches is a very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.Cheers,
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
the branching/merging is much better, so if not anything, but could
solve/make thing easier, especially if we decide to work with more branches
(either for cherry picking, or multiple stable branches, for example the
suggested lts method)
I really like Git (much more than SVN actually) and I use it for all my
projects,
but I doubt moving to Git would solve anything.
IMO even CVS was quite enough for our development model.hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.I think git could be a great help, maintaining multiple branches will
be easier. It will also be very useful to develop new complex features
requiring a longer development period. SVN works fine but merging is
very limited and buggy, maintaining a branch while syncing changes
from trunk/other branches is a very frustrating experiences.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.Cheers,
--
Wbr,
Antony Dovgalhttp://pinba.org - realtime statistics for PHP
GIT is realy nice!
git merging magic!
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.
Before even talking about git; the discussion should focus on whether we
want DVCS. There are other things out there beside gits, which are not
that difficult to use and provide just as much functionality.
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Derick Rethans wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.Before even talking about git; the discussion should focus on whether we
want DVCS. There are other things out there beside gits, which are not
that difficult to use and provide just as much functionality.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.
Ignoring the problems of actually using github I think this is exactly the
problem we are finding with those projects that have pushed over to git.
MANAGING what is allowed back into some master copy of the code base is the bit
that is a lot more difficult than with current arrangements. The result is
several versions of the same projects simply because people are doing their own
things and then nobody knows which version to pull from. The release manager has
to un-pick what should be merged and even on a small project this is time
consuming. If everybody with their own agenda for PHP starts doing their own
builds we will end up with even more branches since they will just be publishing
them ;)
--
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
Derick Rethans wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.Before even talking about git; the discussion should focus on whether we
want DVCS. There are other things out there beside gits, which are not
that difficult to use and provide just as much functionality.Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.Ignoring the problems of actually using github I think this is exactly the
problem we are finding with those projects that have pushed over to git.
MANAGING what is allowed back into some master copy of the code base is the
bit that is a lot more difficult than with current arrangements. The result
is several versions of the same projects simply because people are doing
their own things and then nobody knows which version to pull from. The
release manager has to un-pick what should be merged and even on a small
project this is time consuming. If everybody with their own agenda for PHP
starts doing their own builds we will end up with even more branches since
they will just be publishing them ;)
http://progit.org/book/ch5-1.html
I think we could go with either an Integration Manager kind of workflow, or
with the Dictator and Lieutenants (that is used for the linux development).
either way, with good merging tools, the integrations isn't such of a
problem.
my 2 cents.
Derick Rethans wrote:
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.Ignoring the problems of actually using github I think this is
exactly the problem we are finding with those projects that have
pushed over to git. MANAGING what is allowed back into some master
copy of the code base is the bit that is a lot more difficult than
with current arrangements. The result is several versions of the
same projects simply because people are doing their own things and
then nobody knows which version to pull from. The release manager
has to un-pick what should be merged and even on a small project
this is time consuming. If everybody with their own agenda for PHP
starts doing their own builds we will end up with even more branches
since they will just be publishing them ;)http://progit.org/book/ch5-1.html
I think we could go with either an Integration Manager kind of workflow, or
with the Dictator and Lieutenants (that is used for the linux development).
either way, with good merging tools, the integrations isn't such of a
problem.
Whatever workflow we prefer is not what is guaranteed to happen. I agree
totally with Lester here. DVCS fragments the development team.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.
Developers can already wall themselves off now with the github mirror.
Also, taking a peak at the linux dev mailing list I see lots of
collaboration going on. It makes sense that a developer wanting to
discuss a new feature or patch will push that branch to origin.
What a DVCS does allow for are branches for each specific
project/patch and incremental commits within that branch. That keeps
project/patch commits together and also side-steps the entire issue of
cherry-picking. At work we use git and usually have 6 project
branches with competing and interweaving timeframes. Each developer
has upwards of 50 branches local to them (heck I recently had 105
until I did some cleaning yesterday) that feed the project branches.
We manage this with very few problems and is not something we could do
with cvs or svn.
Ignoring the problems of actually using github I think this is
exactly the problem we are finding with those projects that have
pushed over to git. MANAGING what is allowed back into some master
copy of the code base is the bit that is a lot more difficult than
with current arrangements. The result is several versions of the
same projects simply because people are doing their own things and
then nobody knows which version to pull from. The release manager
has to un-pick what should be merged and even on a small project
this is time consuming. If everybody with their own agenda for PHP
starts doing their own builds we will end up with even more branches
since they will just be publishing them ;)http://progit.org/book/ch5-1.html
I think we could go with either an Integration Manager kind of workflow, or
with the Dictator and Lieutenants (that is used for the linux development).
either way, with good merging tools, the integrations isn't such of a
problem.Whatever workflow we prefer is not what is guaranteed to happen. I agree
totally with Lester here. DVCS fragments the development team.
DVCS does not cause fragmentation. DVCS is a tool. How a development
team uses that tool is up to them.
I don't think anyone seriously considering a migration to git is
thinking that there are no problems. However, the problems Lester is
describing are similar to the problems we have now: people checked in
all kinds of changes to trunk and nobody knows how to pick them apart
to make a stable build. In my experience, managing DVCS is less work
than managing cvs/svn. Sure, individuals and entire development teams
can shoot themselves in the foot if they use DVCS incorrectly. But, I
would rather use a sharp tool (like git) than a dull one (like svn).
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.Developers can already wall themselves off now with the github mirror.
No. People. Stop saying that. It simply isn't true.
The 'github mirror' hasn't been active for 6months.
It got killed because our box simply couldn't handle the job.
-Hannes
Developers can already wall themselves off now with the github mirror.
No. People. Stop saying that. It simply isn't true.
The 'github mirror' hasn't been active for 6months.
It got killed because our box simply couldn't handle the job.
My mistake. The github mirror really isn't the point thought. The
point is that anyone can use git-svn to make a git repo of PHP source
and isolate themselves.
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
Developers can already wall themselves off now with the github mirror.
No. People. Stop saying that. It simply isn't true.
The 'github mirror' hasn't been active for 6months.
It got killed because our box simply couldn't handle the job.My mistake. The github mirror really isn't the point thought. The
point is that anyone can use git-svn to make a git repo of PHP source
and isolate themselves.
Nope you cannot. We forbid total git-svn clones as they put too much traffic
on the svn server. You can run a shallow clone, but either way you will have
a hard time merging and using all the nice DVCS features together when you
use git-svn. git-svn is more a local svn with local feature branches than a full
blown git.
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or another.Before even talking about git; the discussion should focus on whether
we want DVCS. There are other things out there beside gits, which are
not that difficult to use and provide just as much functionality.
Actually, this is the right question... but there's another option.
Offer PHP via as many VCS systems as possible. A number of Apache
projects do this, and have ways to keep the various systems in sync.
This would offer the most flexibility, as well as appease the largest
number of developers.
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration.
That's a pretty broad generalization, and one I've never heard voiced
before. I've actually found exactly the opposite -- DVCS tends to be
more democratic (developers can create and maintain features and share
them easily), and less egocentric (DVCS developers are more willing to
share and cherry-pick than in projects with centralized control). Can
you please qualify the above statement.
You want your stuff exposed to as many developers as possible instead
of walled gardens.
How is SVN not just another such walled garden?
It might be easy enough to share, but discovery is a lot harder.
Perhaps. But that's what mailing lists, issue trackers, and blogs are
for. I've had very little issue with discovery, to be honest.
--
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
On Thu, Nov 25, 2010 at 5:54 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:
It might be easy enough to share, but discovery is a lot harder.
Perhaps. But that's what mailing lists, issue trackers, and blogs are
for. I've had very little issue with discovery, to be honest.
And www.php.net, that's exactly what is meant in the release
management RFC, under the feature preview release. rmtools.php.net can
also be easily adapted to fetch src from git and the build bots will
work just fine as well.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org