As a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee that patches
don't slip through the cracks and don't get lost.
I think we could do with investing a little bit of time into finding a
way to automatically review commits to see if they have been merged to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can then analyze
the commit messages to make sure that commits referencing a particular
bug number have a corresponding set of commits in the branches, and
vice versa.
Once we have that data, we could have job that periodically (daily)
reviews the activity per bug report and sends an email reminder about
reports that have missing merge activity for longer than a week.
--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.
Ilia, I would really like to know why you are not merging patches
to head?Unfortunately I don't have as much time to spend on PHP as I'd like
and I focus my attention on the aspects of PHP I use and can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6 code, with
which I do not have as much familiarity. Rather then making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
Sorry for my initial offlist reply. My evil gmail does not "reply-all"
by default :P
Here is an answer from Wez to my reply:
I'm all for this solution. I asked to do it a couple of years ago (and
a couple of times since). All commits besides CS or docs (inline)
should have a bug report. It is then much easier to track the changes,
the discussions and, as you said here, be sure that all active
branches have it.
To be effective, we'd need to require that all commits reference a bug
report, otherwise one could forget to reference it and we'd "lose" the
commit.
We can create CS and Doc reports to allow those to be made without
opening a report for each one.
What I would like to provide is a way to get the patches related to an
issue from our bug tracker. I'm not sure what's the best way to do it
but at least all related commits can be associated. A cron job can
fetch the commit mails and add them to the respective issues. Or can
we have a special mail sent to a php-bug-patches@php.net with the
complete patch and commit message?
Yeah, I'd love that to work too.
I think mailing into the bugs box would be the way to make it work.
--Wez.
Wez Furlong wrote:
Once we have that data, we could have job that periodically (daily)
reviews the activity per bug report and sends an email reminder about
reports that have missing merge activity for longer than a week.
Wouldnt we then also have to have some flag on the bug to make it clear
what branches of PHP are affected? Otherwise we would have a fair number
of false positives for patches that are fixes that are only required for
a specific branch?
regards,
Lukas
hi folks,
On Monday 28 May 2007 17:56:54 Wez Furlong wrote:
I think we could do with investing a little bit of time into finding a
way to automatically review commits to see if they have been merged to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can then analyze
the commit messages to make sure that commits referencing a particular
bug number have a corresponding set of commits in the branches, and
vice versa.
this would be of immense, immense help to 3rd party distributors of php, such
as debian (and redhat, and others, i'm sure). currently it's a rather
trying experience to go digging through commit histories for something that
was fixed "in the latest cvs snapshot" at some point in time. i think i
posted a feature request along these lines at some time in the past... :)
sean
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time, energy
and devotion. And of course people need to be willing to get used to the
new way of doing things.
Foremost I think we could benefit from moving to SVN. We've had very
good experiences with it and I think it fixes a lot of CVS shortcomings.
The move would of course be quite an undertaking with years and years of
history (and added/removed files).
The Zend Framework project is an example of an open-source project where
we have a more strict dev process. We open bugs for everything using
JIRA (unfortunately Java-based but pretty powerful and integrates nicely
with SVN so that changesets are connected to the bugs), it also allows
us to easily see status of where we are for the release, and there are
some nice perks like being able to auto-generate a list of bug fixes for
a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are also
quite a few other benefits but just by browsing around a db in action
some of those benefits should be visible.
Starting to look at this stuff would take a lot of effort though and not
sure if there are enough able people willing to step up to the plate. I
think starting with a move to SVN would probably be best because a lot
of other apps integrate/depend on it.
Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee that
patches don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time into
finding a way to automatically review commits to see if they
have been merged to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in
all commits (could be enforced by the commit hook); we can
then analyze the commit messages to make sure that commits
referencing a particular bug number have a corresponding set
of commits in the branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an
email reminder about reports that have missing merge activity
for longer than a week.--Wez.
PS: We could also consider posting links to commit URLs to
the associated bug report; this is a feature I really value
in our subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?Unfortunately I don't have as much time to spend on PHP as I'd like
and I focus my attention on the aspects of PHP I use and can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6 code, with
which I do not have as much familiarity. Rather then making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe, visit: http://www.php.net/unsub.php
I really don't think moving to subversion until they finish the merge
tracking code makes much sense. The only advantage pre-1.5 is slightly
better support for other tools that sit on top of it, but even there it
isn't a clear win. There are changeset trackers for CVS as well that
would be a lot easier to add on to our current infrastructure than
switching the entire thing to svn first.
Once Subversion 1.5 comes out (which isn't that far off), the landscape
finally changes and assuming that it works, we'll finally have a real
technological incentive to move.
-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time, energy
and devotion. And of course people need to be willing to get used to the
new way of doing things.
Foremost I think we could benefit from moving to SVN. We've had very
good experiences with it and I think it fixes a lot of CVS shortcomings.
The move would of course be quite an undertaking with years and years of
history (and added/removed files).
The Zend Framework project is an example of an open-source project where
we have a more strict dev process. We open bugs for everything using
JIRA (unfortunately Java-based but pretty powerful and integrates nicely
with SVN so that changesets are connected to the bugs), it also allows
us to easily see status of where we are for the release, and there are
some nice perks like being able to auto-generate a list of bug fixes for
a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are also
quite a few other benefits but just by browsing around a db in action
some of those benefits should be visible.Starting to look at this stuff would take a lot of effort though and not
sure if there are enough able people willing to step up to the plate. I
think starting with a move to SVN would probably be best because a lot
of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee that
patches don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time into
finding a way to automatically review commits to see if they
have been merged to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in
all commits (could be enforced by the commit hook); we can
then analyze the commit messages to make sure that commits
referencing a particular bug number have a corresponding set
of commits in the branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an
email reminder about reports that have missing merge activity
for longer than a week.--Wez.
PS: We could also consider posting links to commit URLs to
the associated bug report; this is a feature I really value
in our subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP as I'd like
and I focus my attention on the aspects of PHP I use and can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6 code, with
which I do not have as much familiarity. Rather then making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe, visit: http://www.php.net/unsub.php
Well I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).
Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.
Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
Well I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.
Also keep in mind that there are plenty of subprojects under
cvs.php.net. These tend to be a lot simpler on the branching/merging
side. So maybe these are good testing grounds to get some of the
infrastructure for karma management in place. And then once we start
feeling comfortable with things, then we are more prepared to move php
internals over.
regards,
Lukas
Hey Lukas,
Also keep in mind that there are plenty of subprojects under cvs.php.net.
These tend to be a lot simpler on the branching/merging side. So maybe
these are good testing grounds to get some of the infrastructure for karma
management in place. And then once we start feeling comfortable with
things, then we are more prepared to move php internals over.
Yep, that's a smart idea. Practically everyone working for php.net touches
the manual at some point or another, so moving the manual across before the
versioned codebase would provide a modicum of pre-training across the board
:)
- Steph
Ouf... Wez and I may have different ideas here, but we were both aiming to
keep it simple. That's because we both know that if it turns into a big
job/makes life more complicated for the dev team, nobody will find the time
or inclination to implement it anyway!
Switching to subversion would mean a learning curve for some, and a change
of PHP development tools and practice for everyone involved in php.net.
It's a major step, particularly at a time when people are finding themselves
stretched anyway (the starting point of this entire issue). Besides, the
whole issue of PECL branch, commit and bug reporting mechanisms needs some
serious thought beforehand, because there are so many niggling problems
there. It'd be better to resolve those problems (at least in a theoretical
sense) before the move than after.
So yeah - a huge job, and not only from the repository admin perspective.
- Steph
----- Original Message -----
From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals List"
internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset tracking
Well I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).
Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.
Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.php
Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
I used to think so, but my experience working with SVN on Framework
shows it's not that different, at least on the level I use it (and
that'd be the level most other people would use it I guess -
checkout/update/diff/commit). So if we talking learning curve, it's not
that different - svn up vs. cvs up :) I don't know though how (and if at
all possible) to port karma system, changelog, etc. but that's admin
stuff already.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved
in php.net. It's a major step, particularly at a time when people areI used to think so, but my experience working with SVN on Framework
shows it's not that different, at least on the level I use it (and
that'd be the level most other people would use it I guess -
checkout/update/diff/commit). So if we talking learning curve, it's not
that different - svn up vs. cvs up :) I don't know though how (and if at
all possible) to port karma system, changelog, etc. but that's admin
stuff already.
Would be nice if svn already had versioning for metadata, but otherwise
it's not that hard to learn (there are even tricks to jump your live tree
from a cvs checkout to an svn checkout, although a cvs diff/svn checkout
and patch is usually simpler.)
The ASF finally set a hard cutoff, and forced the hand. People adapted.
In other works, "svn doesn't suck" :) It's just a slightly different
tool. svn status is a huge improvement over cvs up to locate the diffs
in your current checkout. svn 1.4 finally gives you the chance to
mirror the repository. E.g. if you could do it in cvs, you can do it
(somehow) finally in svn.
The problem, as Rasmus points out, is that a huge repository like php's
naturally doesn't migrate cleanly, and that's not even pointing out the
nightmares of fat fingers crawling around rcs ,v files.
Hi Stas,
I used to think so, but my experience working with SVN on Framework shows
it's not that different, at least on the level I use it (and that'd be the
level most other people would use it I guess -
checkout/update/diff/commit). So if we talking learning curve, it's not
that different - svn up vs. cvs up :) I don't know though how (and if at
all possible) to port karma system, changelog, etc. but that's admin stuff
already.
It's different if you're someone who doesn't really know what a CVS is and
just uses the tool mechanically. That's probably most of the translation
teams, some of the documentation teams, a fair proportion of the PEAR and
smarty folk.... It's a new tool. Windows-based docs people need to use
cygwin to generate a test build on their home pc, so it's a fair bet that
most of them will be using commandline cvs without actually understanding
it. For svn they'll all be downloading something else they don't really
understand (or need to), but that's intimidating for doze people - usually
downloading anything via cygwin means downloading about another 8 things
that you've no idea about (dependencies). It's actually easier for the
coding teams because they can just use tortoisesvn...
Anyway this is 'future talk' so I'll stave off the panic for now :)
- Steph
Also keep in mind that the manual tweaks to the CVS repository over the
past 10+ years means we will likely lose commit history. Last time I
tried the conversion process over a year ago, the commit history was
completely hosed. We will eventually need to migrate, but we have to
recognize that it is going to hurt on many levels.
-Rasmus
Steph Fox wrote:
Ouf... Wez and I may have different ideas here, but we were both aiming
to keep it simple. That's because we both know that if it turns into a
big job/makes life more complicated for the dev team, nobody will find
the time or inclination to implement it anyway!Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
finding themselves stretched anyway (the starting point of this entire
issue). Besides, the whole issue of PECL branch, commit and bug
reporting mechanisms needs some serious thought beforehand, because
there are so many niggling problems there. It'd be better to resolve
those problems (at least in a theoretical sense) before the move than
after.So yeah - a huge job, and not only from the repository admin perspective.
- Steph
----- Original Message ----- From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals
List" internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset trackingWell I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.php
Hello Rasmus,
I wouldn't expect much problems from converting to SVN. What we have to
analyse is how well it can handle all the directoy linking and stuff we
did to overcome the CVS disadvantages. I changed a few repositories my self
and never experienced any issues. Also we are friends with most of the
important developers of SVN so we might be able to get some help. And Last
but not least, if we think about putting a new toolchain on top of what we
have, why bother with old crap then? Just move to where the development
happens. CVS will imho die. And right now the only thing I was missing
from SVN with branch graphs. That is curretnly not possible in SVN but as
far as I know it will be with 1.5. When the import tool is using 1.5 we
should get all we want from the conversion. So why not look for what we
want to do in the future with SVN as the base tool. I also agree to what
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imho a very bad thing to have three databases for bugs.
best regards
marcus
Wednesday, May 30, 2007, 8:04:20 AM, you wrote:
Also keep in mind that the manual tweaks to the CVS repository over the
past 10+ years means we will likely lose commit history. Last time I
tried the conversion process over a year ago, the commit history was
completely hosed. We will eventually need to migrate, but we have to
recognize that it is going to hurt on many levels.
-Rasmus
Steph Fox wrote:
Ouf... Wez and I may have different ideas here, but we were both aiming
to keep it simple. That's because we both know that if it turns into a
big job/makes life more complicated for the dev team, nobody will find
the time or inclination to implement it anyway!Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
finding themselves stretched anyway (the starting point of this entire
issue). Besides, the whole issue of PECL branch, commit and bug
reporting mechanisms needs some serious thought beforehand, because
there are so many niggling problems there. It'd be better to resolve
those problems (at least in a theoretical sense) before the move than
after.So yeah - a huge job, and not only from the repository admin perspective.
- Steph
----- Original Message ----- From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals
List" internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset trackingWell I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.php
Best regards,
Marcus
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imho a very bad thing to have three databases for bugs.
Amen.
- Steph
I already said that svn 1.5 looks interesting. And it will hopefully
finally be worth the effort to migrate. And I wasn't just guessing that
we would have trouble migrating the repository. I actually tried it,
and the history was completely hosed. It requires manual intervention
to clean up. On a small repository, that's easy. On ours?
All this takes is for someone to volunteer a couple of weeks of their
life to this. This is not a weekend effort for someone. Beyond trying
to restore the history, there are a lot of scripts that need to be
written around the user account management and ACLs.
There is no barrier for someone to get started on this. Just cvsup the
repository and have a go and report back.
-Rasmus
Marcus Boerger wrote:
Hello Rasmus,
I wouldn't expect much problems from converting to SVN. What we have to
analyse is how well it can handle all the directoy linking and stuff we
did to overcome the CVS disadvantages. I changed a few repositories my self
and never experienced any issues. Also we are friends with most of the
important developers of SVN so we might be able to get some help. And Last
but not least, if we think about putting a new toolchain on top of what we
have, why bother with old crap then? Just move to where the development
happens. CVS will imho die. And right now the only thing I was missing
from SVN with branch graphs. That is curretnly not possible in SVN but as
far as I know it will be with 1.5. When the import tool is using 1.5 we
should get all we want from the conversion. So why not look for what we
want to do in the future with SVN as the base tool. I also agree to what
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imho a very bad thing to have three databases for bugs.best regards
marcusWednesday, May 30, 2007, 8:04:20 AM, you wrote:
Also keep in mind that the manual tweaks to the CVS repository over the
past 10+ years means we will likely lose commit history. Last time I
tried the conversion process over a year ago, the commit history was
completely hosed. We will eventually need to migrate, but we have to
recognize that it is going to hurt on many levels.-Rasmus
Steph Fox wrote:
Ouf... Wez and I may have different ideas here, but we were both aiming
to keep it simple. That's because we both know that if it turns into a
big job/makes life more complicated for the dev team, nobody will find
the time or inclination to implement it anyway!Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
finding themselves stretched anyway (the starting point of this entire
issue). Besides, the whole issue of PECL branch, commit and bug
reporting mechanisms needs some serious thought beforehand, because
there are so many niggling problems there. It'd be better to resolve
those problems (at least in a theoretical sense) before the move than
after.So yeah - a huge job, and not only from the repository admin perspective.
- Steph
----- Original Message ----- From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals
List" internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset trackingWell I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.phpBest regards,
Marcus
Rasmus, hi,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch releases
and PECL extension development. Both issues now will need thinking through
in svn terms as well as in cvs terms, if they're to be resolved at all.
Two weeks doesn't sound long enough.
- Steph
I already said that svn 1.5 looks interesting. And it will hopefully
finally be worth the effort to migrate. And I wasn't just guessing that
we would have trouble migrating the repository. I actually tried it,
and the history was completely hosed. It requires manual intervention
to clean up. On a small repository, that's easy. On ours?All this takes is for someone to volunteer a couple of weeks of their
life to this. This is not a weekend effort for someone. Beyond trying
to restore the history, there are a lot of scripts that need to be
written around the user account management and ACLs.There is no barrier for someone to get started on this. Just cvsup the
repository and have a go and report back.-Rasmus
Marcus Boerger wrote:
Hello Rasmus,
I wouldn't expect much problems from converting to SVN. What we have to
analyse is how well it can handle all the directoy linking and stuff we
did to overcome the CVS disadvantages. I changed a few repositories my
self
and never experienced any issues. Also we are friends with most of the
important developers of SVN so we might be able to get some help. And
Last
but not least, if we think about putting a new toolchain on top of what
we
have, why bother with old crap then? Just move to where the development
happens. CVS will imho die. And right now the only thing I was missing
from SVN with branch graphs. That is curretnly not possible in SVN but as
far as I know it will be with 1.5. When the import tool is using 1.5 we
should get all we want from the conversion. So why not look for what we
want to do in the future with SVN as the base tool. I also agree to what
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imho a very bad thing to have three databases for bugs.best regards
marcusWednesday, May 30, 2007, 8:04:20 AM, you wrote:
Also keep in mind that the manual tweaks to the CVS repository over the
past 10+ years means we will likely lose commit history. Last time I
tried the conversion process over a year ago, the commit history was
completely hosed. We will eventually need to migrate, but we have to
recognize that it is going to hurt on many levels.-Rasmus
Steph Fox wrote:
Ouf... Wez and I may have different ideas here, but we were both aiming
to keep it simple. That's because we both know that if it turns into a
big job/makes life more complicated for the dev team, nobody will find
the time or inclination to implement it anyway!Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
finding themselves stretched anyway (the starting point of this entire
issue). Besides, the whole issue of PECL branch, commit and bug
reporting mechanisms needs some serious thought beforehand, because
there are so many niggling problems there. It'd be better to resolve
those problems (at least in a theoretical sense) before the move than
after.So yeah - a huge job, and not only from the repository admin
perspective.
- Steph
----- Original Message ----- From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals
List" internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset trackingWell I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingI really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.-Rasmus
Andi Gutmans wrote:
In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.Andi
-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset trackingAs a fellow busy person, I completely understand this situation.
I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.--Wez.
PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.Ilia Alshanetsky
--
To
unsubscribe,
visit: http://www.php.net/unsub.php--
To
unsubscribe,
visit: http://www.php.net/unsub.phpBest regards,
Marcus
Steph Fox wrote:
Rasmus, hi,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch
releases and PECL extension development. Both issues now will need
thinking through in svn terms as well as in cvs terms, if they're to be
resolved at all.Two weeks doesn't sound long enough.
Well, the problem is that if the work involved to do this is in any way
CVS-specific, it will be throw-away work once we move away from CVS,
which is inevitable. What we don't know at this point is the lifespan
of CVS. I'm unmotivated to do anything with SVN with the major 1.5
release coming up in a month or two. But if someone else is gung ho
enough to volunteer sooner and has an eye on 1.5 to make sure the stuff
will be compatible with the new release, perhaps things can move quicker.
-Rasmus
Rasmus,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch
releases and PECL extension development. Both issues now will need
thinking through in svn terms as well as in cvs terms, if they're to be
resolved at all.Two weeks doesn't sound long enough.
Well, the problem is that if the work involved to do this is in any way
CVS-specific, it will be throw-away work once we move away from CVS,
which is inevitable.
I agree entirely - that's exactly what I meant by 'thinking through in svn
terms as well as in cvs terms'.
What we don't know at this point is the lifespan
of CVS. I'm unmotivated to do anything with SVN with the major 1.5
release coming up in a month or two. But if someone else is gung ho
enough to volunteer sooner and has an eye on 1.5 to make sure the stuff
will be compatible with the new release, perhaps things can move quicker.
Given that this entire thread came about because at least two of the core
team don't have time to deal with merging to HEAD, that doesn't seem very
likely. But you're right to put an end to quick-fix and possibly
cvs-specific solutions. Does svn even support validation scripting? Does
anyone even know without checking?
Lukas was onto a good thing with his idea of moving less challenging areas
of the CVS repository to SVN first IMHO. It'll make the task of moving the
difficult ones less horrendous, and it'll give some idea of the problems
likely to be encountered in adoption (if any).
- Steph
Given that this entire thread came about because at least two of the core
team don't have time to deal with merging to HEAD, that doesn't seem very
likely. But you're right to put an end to quick-fix and possibly
cvs-specific solutions. Does svn even support validation scripting? Does
anyone even know without checking?
The code to do the first part of what I described is just a bit perl,
or can be easily tweaked to perl, and run in our environment without
too much hassle. It will be marginally cvs dependent, but less work
that making it work for svn; I think its totally worth it.
SVN does indeed support validation... how else do you think we
implement the checks I described earlier in the thread? :-)
Lukas was onto a good thing with his idea of moving less challenging areas
of the CVS repository to SVN first IMHO. It'll make the task of moving the
difficult ones less horrendous, and it'll give some idea of the problems
likely to be encountered in adoption (if any).
As Rasmus said, it's a job for someone to sit down with a copy of the
repository, cvs2svn, a lot of time, and a lot of patience, to make the
migration work... but we're not stopping anyone from volunteering :)
--Wez.
Wez Furlong wrote:
As Rasmus said, it's a job for someone to sit down with a copy of the
repository, cvs2svn, a lot of time, and a lot of patience, to make the
migration work... but we're not stopping anyone from volunteering :)
I converted our company's CVS to SVN a while ago and might be willing to
give it a try as I'm familiar with basic SVN setup, commit hooks and
cvs2svn.
I didn't follow this thread really so I'm not up-to-date with the
requirements of the version control setup, i.e. what CVS features / view
(web, anon and authenticated access) you currently use.
Is there a summary of the requirements somewhere? Who's in charge of the
CVS setup right now?
- Chris
Well, the problem is that if the work involved to do this is in any way
CVS-specific, it will be throw-away work once we move away from CVS,
which is inevitable. What we don't know at this point is the lifespan
of CVS. I'm unmotivated to do anything with SVN with the major 1.5
You keep repeating "inevitable", but exactly what is the "inevitable"
here? AFAIK, CVS works fine: don't fix if it isn't broken!
I'd like to here the (real) reasons why the switch would be beneficial
for project like PHP.
I'm using both CVS and SVN daily, but I still prefer CVS..perhaps I'm
just old-fashioned..:)
--Jani
Jani Taskinen wrote:
Well, the problem is that if the work involved to do this is in any way
CVS-specific, it will be throw-away work once we move away from CVS,
which is inevitable. What we don't know at this point is the lifespan
of CVS. I'm unmotivated to do anything with SVN with the major 1.5You keep repeating "inevitable", but exactly what is the "inevitable"
here? AFAIK, CVS works fine: don't fix if it isn't broken!
I'd like to here the (real) reasons why the switch would be beneficial
for project like PHP.
I keep repeating? I have said that exactly once.
The problem with CVS is that nobody is working on improving it. There
are a lot of features in modern source control systems that we will
never see in CVS. Not that subversion has them yet either, but with
version 1.5 they are moving in the right direction.
Some of the things that would directly benefit the project:
-
Easier to handle changesets
this can be hacked onto CVS, but nobody has done this yet for
cvs.php.net -
Sparse checkouts (1.5)
Ever try checking out phpweb and get stuck waiting for all the
distribution tarballs to download or having your disk fill up
because of it? -
Better performance
-
Atomic commits
-
Merge tracking (1.5)
Andi mentioned that our process wouldn't benefit from this, but
I think that is a case of our process being set up to match the
limitation of the tool and not necessarily because it is the
best way to do things. With merge tracking you get repeated
merges and the ability to cherry pick changes from one branch
without messing up the previous or subsequent merges. -
svn blame, status and diff --summarize are all quite handy
-
It would be nice to have real rename and move support to avoid the
manual repository hacks -
Better integration with external tools
The big negatives are of course:
-
We lose real tagging
-
We will lose commit history on some files
-
Our less technical users will be confused for a while
-
The development process will be affected
-Rasmus
I also said inevitable :) For the reasons Rasmus mentions it makes very
much sense for us to move to SVN.
Over the years, as the PHP project has grown, we have increasingly felt
the shortcomings of CVS. In addition, there are likely to be additional
ways SVN can benefit our dev process.
At the end of the day, the main pain will be felt by the people who
actually migrate the data and supporting systems. For the end user it
won't take a lot to adapt. Also, we may loose some history even with
manual intervention, but we can/should keep the old CVS repository
around (maybe in museum.php.net) so that we will always have access to
the past... In any case we will hopefully be able to save the majority
of the metadata.
As we expect many more years for PHP we should make sure that the train
we're riding has momentum and can help us continue to scale our dev
process. I think SVN is the right train to hop onto.
Andi
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Wednesday, May 30, 2007 7:57 AM
To: sniper@iki.fi
Cc: PHP Internals List
Subject: Re: [PHP-DEV] better changeset trackingJani Taskinen wrote:
Well, the problem is that if the work involved to do this
is in any
way CVS-specific, it will be throw-away work once we move
away from
CVS, which is inevitable. What we don't know at this point is the
lifespan of CVS. I'm unmotivated to do anything with SVN with the
major 1.5You keep repeating "inevitable", but exactly what is the
"inevitable"
here? AFAIK, CVS works fine: don't fix if it isn't broken!
I'd like to here the (real) reasons why the switch would be
beneficial
for project like PHP.I keep repeating? I have said that exactly once.
The problem with CVS is that nobody is working on improving
it. There are a lot of features in modern source control
systems that we will never see in CVS. Not that subversion
has them yet either, but with version 1.5 they are moving in
the right direction.Some of the things that would directly benefit the project:
Easier to handle changesets
this can be hacked onto CVS, but nobody has done this yet for
cvs.php.netSparse checkouts (1.5)
Ever try checking out phpweb and get stuck waiting for all the
distribution tarballs to download or having your disk fill up
because of it?Better performance
Atomic commits
Merge tracking (1.5)
Andi mentioned that our process wouldn't benefit from this, but
I think that is a case of our process being set up to match the
limitation of the tool and not necessarily because it is the
best way to do things. With merge tracking you get repeated
merges and the ability to cherry pick changes from one branch
without messing up the previous or subsequent merges.svn blame, status and diff --summarize are all quite handy
It would be nice to have real rename and move support to avoid the
manual repository hacksBetter integration with external tools
The big negatives are of course:
We lose real tagging
We will lose commit history on some files
Our less technical users will be confused for a while
The development process will be affected
-Rasmus
--
To
unsubscribe, visit: http://www.php.net/unsub.php
Hi,
So I guess what we need is to figure out a bit what our current
development process is, what if it we actually want to keep and what we
are hoping to get in the future. Maybe we can brainstorm at php|vikinger
on this. One of the "processes" we have is that we have no formal
processes and for better or for worse, this is how PHP works (and the
german in me is slowly accepting this), so all I want is to provide some
analysis, that may more may not be used by the people that actually make
the change happen eventually.
@Steph: are you coming to vikinger, and if not could you write up
something about your perception of the commit process?
regards,
Lukas
Hi,
As we expect many more years for PHP we should make sure that the train
we're riding has momentum and can help us continue to scale our dev
process. I think SVN is the right train to hop onto.
I would like to propose Git. I think it is more appropriate for large
projects like PHP. I do not have the time to provide a full list of
its advantages or features but here are some of its huge advantages:
- user tree
- its ability to push patches from a tree to another
- CVS bridge (non developers can still checkout/provide patches using cvs)
For example, it is possible to have (only examples! :): Dmitry working
on a complete rewrite of the engine, Stan is fixing TSRM and the QA
fixing the stable/dev trees. The RMs can still prepare releases in the
main tree.
The release manager can then safely choose which patches should be
pushed. The developers do not have to take care about the release
process in their trees. Experiments can be done safely in a tree and
merged (even partially) when they are ready.
freedesktop has moved to GIT some time ago and for what I heard from
the developers, it is a huge improvement in their development process.
The only bad point (which exists with any other migratrion) is the
time required to learn the new tool.
--Pierre
Pierre wrote:
Hi,
As we expect many more years for PHP we should make sure that the train
we're riding has momentum and can help us continue to scale our dev
process. I think SVN is the right train to hop onto.I would like to propose Git. I think it is more appropriate for large
projects like PHP. I do not have the time to provide a full list of
its advantages or features but here are some of its huge advantages:
- user tree
- its ability to push patches from a tree to another
- CVS bridge (non developers can still checkout/provide patches using cvs)
For example, it is possible to have (only examples! :): Dmitry working
on a complete rewrite of the engine, Stan is fixing TSRM and the QA
fixing the stable/dev trees. The RMs can still prepare releases in the
main tree.The release manager can then safely choose which patches should be
pushed. The developers do not have to take care about the release
process in their trees. Experiments can be done safely in a tree and
merged (even partially) when they are ready.freedesktop has moved to GIT some time ago and for what I heard from
the developers, it is a huge improvement in their development process.
The only bad point (which exists with any other migratrion) is the
time required to learn the new tool.
Which I think is the fatal flaw for a project this large. Git is also
not very refined. If you are going to stray that far from the
centralized repository approach then bzr is probably a better bet.
With merge-tracking and cherry picking coming in Subversion you get much
of the same benefits without turning the world upside down.
-Rasmus
freedesktop has moved to GIT some time ago and for what I heard from
the developers, it is a huge improvement in their development process.
The only bad point (which exists with any other migratrion) is the
time required to learn the new tool.Which I think is the fatal flaw for a project this large. Git is also
not very refined. If you are going to stray that far from the
centralized repository approach then bzr is probably a better bet.
bzr is nice too but horribly slow. However the main argument is about
having decentralized repositories. It is something that can really
help us and brings more flexibility.
That being said, I can live with any system, I'm (relatively) flexible :)
--Pierre
With merge-tracking and cherry picking coming in Subversion you get much
of the same benefits without turning the world upside down.
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
Regards,
Stefan
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
I used it under cygwin and works well as far as I can tell (be sure to
use the latest). Having a cvs bridge can help too, both to test builds
(not only on windows) or to provide patches.
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
Did they not claim that SVN was perfect for such tasks in 1.0? ;-)
--Pierre
Stefan Walk wrote:
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
svnmerge.py: http://www.orcaware.com/svn/wiki/Svnmerge.py
can help quite a lot as it maintains merges. And as it stores the merge
information in SVN properties I'm sure the information can be converted
to something suitable to use with the SVN 1.5 mechanism.
Having looked at git and others I'm still happy with our move to SVN as
it is almost a drop-in replacement for CVS (substitute cvs for svn on
the command line) for a lot of common operations.
- Chris
I apologize in advance for jumping into this thread so late (finally
trying to catch up on internals@).
FWIW, I'd also like to move to SVN, eventually (and inevitably (-: ).
I've opposed this move for php.net in the past, but only because the
proposals I was fighting were for a partial conversion (e.g. I was
against moving /only/ phpdoc (and associated modules) to svn).
Some of the things that would directly benefit the project:
- svn:externals instead of CVSROOT/modules is much cleaner and more
robust - sane hooks mechanism
- sane svn output parsing for scripts
- better and real (ie, not hacked on) support for users and ACLs
- revision numbering (useful for some phpdoc tools)
- SVN is (mostly) intuitive for CVS users. The process is nearly the
same, and it's not a big shift like git or darcs, etc. - offline diff and status
The big negatives are of course:
- We lose real tagging
~ sort of. We could restrict the subproject/tags ACL to release
manager(s), and each commit gets a revision so that could serve as a
"real" tag for people who want to (e.g.) tag "PRE-DOC-SPLIT".
- We will lose commit history on some files
- ESPECIALLY for the ugly symlinks and moves from php-src to PECL.
This is going to be a mess.
- The development process will be affected
- Specifically, it's going to be a big pain to stop all commits while
we do the switch, and then sync everyone up afterwards.
S