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