better changeset tracking

> 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 >>> >> >>> >> >>> > >>> >>> >>

>> 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.

> 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.