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
