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" <[EMAIL PROTECTED]>
To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
Cc: "Wez Furlong" <[EMAIL PROTECTED]>; "Ilia Alshanetsky"
<[EMAIL PROTECTED]>; "Edin Kadribasic" <[EMAIL PROTECTED]>; "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:[EMAIL PROTECTED]
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 tracking
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:[EMAIL PROTECTED]
>> Sent: Monday, May 28, 2007 8:57 AM
>> To: Ilia Alshanetsky
>> Cc: Edin Kadribasic; PHP Internals List
>> Subject: [PHP-DEV] better changeset tracking
>>
>> 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.
>>
>> On 5/26/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
>>> On 26-May-07, at 6:51 AM, Edin Kadribasic wrote:
>>>
>>>> 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
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List To
>> unsubscribe,
>>> visit: http://www.php.net/unsub.php
>>>
>>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List To
unsubscribe,
>> visit: http://www.php.net/unsub.php
>>
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
