Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <465D13E4.9050201@lerdorf.com>
Date: Tue, 29 May 2007 23:04:20 -0700
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
CC: Andi Gutmans <andi@zend.com>, Wez Furlong <kingwez@gmail.com>,
        Ilia Alshanetsky <ilia@prohost.org>, Edin Kadribasic <edin@krug.dk>,
        PHP Internals List <internals@lists.php.net>
References: <4e89b4260705280856t47429e54ofcc182e02a6627e5@mail.gmail.com> <698DE66518E7CA45812BD18E807866CE3AFF97@us-ex1.zend.net> <465CFFF8.7070603@lerdorf.com> <698DE66518E7CA45812BD18E807866CE3AFFA2@us-ex1.zend.net> <001d01c7a27f$6d12bf80$39dc2f52@foxbox>
In-Reply-To: <001d01c7a27f$6d12bf80$39dc2f52@foxbox>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] better changeset tracking
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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 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 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: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 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 <ilia@prohost.org> 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
>> >>
>> >>
>> >
>>
>>
>