Re: better changeset tracking

Rasmus, hi, We've kinda moved away from the problem in hand. Moving the entire repository over to svn doesn't make it any easier to know when someone commits something that should be merged and doesn't merge it. It also doesn't do anything to resolve the relationship between PHP branch releases and PECL extension development. Both issues now will need thinking through in svn terms as well as in cvs terms, if they're to be resolved at all. Two weeks doesn't sound long enough. - Steph

I already said that svn 1.5 looks interesting. And it will hopefully finally be worth the effort to migrate. And I wasn't just guessing that we would have trouble migrating the repository. I actually tried it, and the history was completely hosed. It requires manual intervention to clean up. On a small repository, that's easy. On ours? All this takes is for someone to volunteer a couple of weeks of their life to this. This is not a weekend effort for someone. Beyond trying to restore the history, there are a lot of scripts that need to be written around the user account management and ACLs. There is no barrier for someone to get started on this. Just cvsup the repository and have a go and report back. -Rasmus Marcus Boerger wrote:

Hello Rasmus, I wouldn't expect much problems from converting to SVN. What we have to analyse is how well it can handle all the directoy linking and stuff we did to overcome the CVS disadvantages. I changed a few repositories my self and never experienced any issues. Also we are friends with most of the important developers of SVN so we might be able to get some help. And Last but not least, if we think about putting a new toolchain on top of what we have, why bother with old crap then? Just move to where the development happens. CVS will imho die. And right now the only thing I was missing from SVN with branch graphs. That is curretnly not possible in SVN but as far as I know it will be with 1.5. When the import tool is using 1.5 we should get all we want from the conversion. So why not look for what we want to do in the future with SVN as the base tool. I also agree to what Wez said. A few more columns in the bugs database would help a lot. And last but not least bug numbers could contain something like P for PHP, L for PECL and R for PEAR. That way it is clear where they came from. Another way is to extend them with a first digit and then merge the tables. It is imho a very bad thing to have three databases for bugs. best regards marcus Wednesday, May 30, 2007, 8:04:20 AM, you wrote:

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

Best regards, Marcus