# better changeset tracking - Thread: https://externals.io/message/29846 - Original archive: https://news-web.php.net/php.internals/29846 - Started by Wez Furlong on 2007-05-28T15:56:54+00:00 - Messages: 39 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/29846.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #29846 — Wez Furlong — 2007-05-28T15:56:54+00:00 URL: https://externals.io/message/29846#29846 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. > > > > > […] > > 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 --- ## #29847 — Pierre — 2007-05-28T16:51:36+00:00 URL: https://externals.io/message/29846#29847 · In reply to: #29846 Sorry for my initial offlist reply. My evil gmail does not "reply-all" by default :P Here is an answer from Wez to my reply: > I'm all for this solution. I asked to do it a couple of years ago (and > a couple of times since). All commits besides CS or docs (inline) > should have a bug report. It is then much easier to track the changes, > the discussions and, as you said here, be sure that all active > branches have it. To be effective, we'd need to require that all commits reference a bug report, otherwise one could forget to reference it and we'd "lose" the commit. We can create CS and Doc reports to allow those to be made without opening a report for each one. > What I would like to provide is a way to get the patches related to an > issue from our bug tracker. I'm not sure what's the best way to do it > but at least all related commits can be associated. A cron job can > fetch the commit mails and add them to the respective issues. Or can > we have a special mail sent to a php-bug-patches@php.net with the > complete patch and commit message? Yeah, I'd love that to work too. I think mailing into the bugs box would be the way to make it work. --Wez. --- ## #29848 — Lukas Kahwe Smith — 2007-05-28T19:16:36+00:00 URL: https://externals.io/message/29846#29848 · In reply to: #29846 Wez Furlong wrote: > 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. Wouldnt we then also have to have some flag on the bug to make it clear what branches of PHP are affected? Otherwise we would have a fair number of false positives for patches that are fixes that are only required for a specific branch? regards, Lukas --- ## #29854 — sean finney — 2007-05-28T22:59:39+00:00 URL: https://externals.io/message/29846#29854 · In reply to: #29846 hi folks, On Monday 28 May 2007 17:56:54 Wez Furlong wrote: > 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. this would be of immense, immense help to 3rd party distributors of php, such as debian (and redhat, and others, i'm sure). currently it's a rather trying experience to go digging through commit histories for something that was fixed "in the latest cvs snapshot" at some point in time. i think i posted a feature request along these lines at some time in the past... :) sean --- ## #29857 — Steph Fox — 2007-05-29T03:26:07+00:00 URL: https://externals.io/message/29846#29857 Hi Wez, >I think the key is in forcing every commit to reference a ticket; that > way you can't "lose" a changeset by forgetting to put a bug number in > there. Going back on-list... It's a good idea in principle, but I can foresee some problems with it. Many (most?) of the unnumbered fixes Ilia's been making have been alterations to internal string or memory function calls. Generally those are either performance or security changes, replicated throughout the code base and starting with a single 'blast' aimed at upgrading everything, followed by lots of smaller catch-up fixes over the next several weeks. This kind of thing isn't really worthy of a bug report, unless you have an entirely new concept of what a bug might be and allow for change types like 'maintenance', 'security' or 'performance' via the bug database somehow. The nearest we've come to that recently is MOPB - everyone marked those fixes as such - and occasionally coverity. If the bug db allows it it might make sense to put an initial function change as a 'maintenance' report with some explanation and a number, e.g.: helly Sat Feb 24 18:20:46 2007 UTC Modified files: (Branch: PHP_5_2) /php-src/main snprintf.c snprintf.h Log: - Add [v]slprintf to overcome the returnvalues issue of snprintf would get a fuller explanation on the report, and every subsequent "snprintf() -> slprintf()" commit would reference that maintenance report number. Fine, but what to do about "malloc() -> pemalloc()"? Would all 'maintenance' fixes require a test script? Wouldn't the need to check for a maintenance number put devs off making a simple one-line fix? Branch-specific fixes are generally (but not always) marked as such at present. People tend to mention it in the 5_2 branch but not in 4_4. - Steph --- ## #29914 — Wez Furlong — 2007-05-29T23:58:42+00:00 URL: https://externals.io/message/29846#29914 · In reply to: #29857 We use trac as an engineering ticketing system; we open tickets to track things that need doing, be they bug fixes, enhancements or other maintenance work. We require that every commit to portions of the repos that contain code reference a ticket number in trac, and reject commits that don't. As you said, it's pretty straightforward to handle bugs this way, but a pain to open a ticket for every little maintenance job. We solve that problem by opening up a maintenance ticket per milestone (eg: X.Y.Z release maintenance ticket) and use that as a catch all for those misc commits. When we're done with working on a ticket in trunk, we set its priority to merge so that we know that it is ready to be considered for merging down to the stable branch(es), and we close it only when that merging is complete. This process should be pretty easy to translate to php.net development. I'm not saying that this is the one true way to do development, but it works for us at OmniTI. --Wez. > Hi Wez, > > > […] > > Going back on-list... It's a good idea in principle, but I can foresee some > problems with it. > > Many (most?) of the unnumbered fixes Ilia's been making have been > alterations to internal string or memory function calls. Generally those are > either performance or security changes, replicated throughout the code base > and starting with a single 'blast' aimed at upgrading everything, followed > by lots of smaller catch-up fixes over the next several weeks. This kind of > thing isn't really worthy of a bug report, unless you have an entirely new > concept of what a bug might be and allow for change types like > 'maintenance', 'security' or 'performance' via the bug database somehow. The > nearest we've come to that recently is MOPB - everyone marked those fixes as > such - and occasionally coverity. > > If the bug db allows it it might make sense to put an initial function > change as a 'maintenance' report with some explanation and a number, e.g.: > > helly Sat Feb 24 18:20:46 2007 UTC > > Modified files: (Branch: PHP_5_2) > /php-src/main snprintf.c snprintf.h > Log: > - Add [v]slprintf to overcome the returnvalues issue of snprintf > > would get a fuller explanation on the report, and every subsequent > "snprintf() -> slprintf()" commit would reference that maintenance report > number. Fine, but what to do about "malloc() -> pemalloc()"? Would all > 'maintenance' fixes require a test script? Wouldn't the need to check for a > maintenance number put devs off making a simple one-line fix? > > Branch-specific fixes are generally (but not always) marked as such at > present. People tend to mention it in the 5_2 branch but not in 4_4. > > - Steph --- ## #29915 — Steph Fox — 2007-05-30T00:12:03+00:00 URL: https://externals.io/message/29846#29915 · In reply to: #29914 Hi Wez, > As you said, it's pretty straightforward to handle bugs this way, but > a pain to open a ticket for every little maintenance job. We solve > that problem by opening up a maintenance ticket per milestone (eg: > X.Y.Z release maintenance ticket) and use that as a catch all for > those misc commits. > > When we're done with working on a ticket in trunk, we set its priority > to merge so that we know that it is ready to be considered for merging > down to the stable branch(es), and we close it only when that merging > is complete. This could work, except of course we don't have any such thing as 'a maintenance ticket' or a way to set priority to 'merge'. It's kind of the opposite way around to the way the PHP bug system works... and it probably would be a pain to have it as part of an open system (in the sense that users can add to it). Perhaps adapt the bugs *interface* to deal with maintenance tickets along the lines you suggest, but with a separate db and ID system - so we get #M9999 rather than #9999, and 'merge', 'no-merge', 'close' as the options? > This process should be pretty easy to translate to php.net > development. I'm not saying that this is the one true way to do > development, but it works for us at OmniTI. It's the difference between a controlled environment and open source.... but I can see it working if the 'per milestone' route is taken, that's a good idea. Anyone with QA/bugs karma care to intervene at this point? - Steph > > --Wez. > > > > > […] --- ## #29921 — Wez Furlong — 2007-05-30T01:10:31+00:00 URL: https://externals.io/message/29846#29921 · In reply to: #29915 > This could work, except of course we don't have any such thing as 'a > maintenance ticket' or a way to set priority to 'merge'. It's kind of the > opposite way around to the way the PHP bug system works... and it probably > would be a pain to have it as part of an open system (in the sense that > users can add to it) I don't see why we can't just add a field or two to the existing database to cater to this--we've got the source ;-). It's much simpler to have one source of ticket numbers--it's then very clear to everyone where you go to create and maintain tickets as well as where you go to read up on them. Personally, I find it quite a pain to have to look in both the pecl and php bug databases to track bugs for PDO; I'd like to avoid adding to that pain by having yet another set of ticket numbers to reference. We can solve the problem with peons and serfs adding to the db by using authentication, just like we do now for the developer aspects to the bugs db. > It's the difference between a controlled environment and open source.... > but I can see it working if the 'per milestone' route is taken, that's a > good idea. Anyone with QA/bugs karma care to intervene at this point? Well, what we're really discussing here is adding some enforced controls to our open source development. My suggestion is a pretty light-weight modification to what we have now, and doesn't intrude terribly on getting stuff done. - add a maintenance category to bug db - add merge status to bug db - add commit hook to detect a bug number in the commit log. - add some method of automatically commenting on bug reports with the commit message and urls to the diffs that's the basic bit to facilitate manual review. The next step from there is writing that cron job to analyze tickets with missing merge activity. This is easily the hardest part to implement; I'd suggest doing that last--nothing else depends on it being there, it's just a convenience to avoid manual review of everything, and we might find that we don't need it after all if we're good at respecting the merge status. --Wez. --- ## #29922 — Steph Fox — 2007-05-30T01:36:10+00:00 URL: https://externals.io/message/29846#29922 · In reply to: #29921 > > > […] > > I don't see why we can't just add a field or two to the existing > database to cater to this--we've got the source ;-). > It's much simpler to have one source of ticket numbers--it's then very > clear to everyone where you go to create and maintain tickets as well > as where you go to read up on them. > > Personally, I find it quite a pain to have to look in both the pecl > and php bug databases to track bugs for PDO; I'd like to avoid adding > to that pain by having yet another set of ticket numbers to reference. Yeah that's why I said 'use the same interface'. > We can solve the problem with peons and serfs adding to the db by > using authentication, just like we do now for the developer aspects to > the bugs db. We can, but it doesn't solve the problem that the one-line commit process would be made more painful than it currently is. Automatic addition to the database for any commit that doesn't quote a reference number would solve that. That would also mean you can't manually open a maintenance ticket even if you _are_ Jesus, as is the case with many of our folk. Still, this concept relies heavily on the idea that it's possible to append generated text to a CVS commit message, and if it isn't - it won't work. > > […] > > Well, what we're really discussing here is adding some enforced > controls to our open source development. My suggestion is a pretty > light-weight modification to what we have now, and doesn't intrude > terribly on getting stuff done. I think it _does_ intrude terribly, which is why I'm advocating automation. But others may differ. > - add a maintenance category to bug db > - add merge status to bug db And 'no-merge'... and something like [NFM] to indicate it from scratch... > - add commit hook to detect a bug number in the commit log. > - add some method of automatically commenting on bug reports with the > commit message and urls to the diffs Yep, my approach was relying on those additions too. > that's the basic bit to facilitate manual review. > > The next step from there is writing that cron job to analyze tickets > with missing merge activity. This is easily the hardest part to > implement; In my dream, you'd just ask the db to show all tickets with 'merge' status; everything else maintenance-wise will automatically be either closed or else marked 'no-merge'. I'd suggest doing that last--nothing else depends on it > being there, it's just a convenience to avoid manual review of > everything, and we might find that we don't need it after all if we're > good at respecting the merge status. We aren't :) Maybe somewhere between both our sets of ideas there's something that'll work out without too much pain. > > --Wez. --- ## #29927 — Andi Gutmans — 2007-05-30T04:12:01+00:00 URL: https://externals.io/message/29846#29927 · In reply to: #29846 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. > > > > […] > patches to > > […] > have tangible > > […] > unsubscribe, > > […] > > -- > To > unsubscribe, visit: http://www.php.net/unsub.php --- ## #29928 — Rasmus Lerdorf — 2007-05-30T04:39:20+00:00 URL: https://externals.io/message/29846#29928 · In reply to: #29927 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 > > > > […] --- ## #29929 — Andi Gutmans — 2007-05-30T05:18:16+00:00 URL: https://externals.io/message/29846#29929 · In reply to: #29928 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: > > […] > had very > > […] > shortcomings. > > […] > and years > > […] > everything > > […] > are for the > > […] > though and > > […] > that patches > > […] > into finding > > […] > been merged > > […] > then analyze > > […] > as I'd like > > […] > can tests > > […] > code, with > > […] > making commits > > […] > unsubscribe, > > […] --- ## #29931 — Lukas Kahwe Smith — 2007-05-30T05:43:17+00:00 URL: https://externals.io/message/29846#29931 · In reply to: #29929 Andi Gutmans wrote: > 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. Also keep in mind that there are plenty of subprojects under cvs.php.net. These tend to be a lot simpler on the branching/merging side. So maybe these are good testing grounds to get some of the infrastructure for karma management in place. And then once we start feeling comfortable with things, then we are more prepared to move php internals over. regards, Lukas --- ## #29932 — Steph Fox — 2007-05-30T05:57:35+00:00 URL: https://externals.io/message/29846#29932 · In reply to: #29929 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" To: "Rasmus Lerdorf" Cc: "Wez Furlong" ; "Ilia Alshanetsky" ; "Edin Kadribasic" ; "PHP Internals List" 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: > > […] > had very > > […] > shortcomings. > > […] > and years > > […] > everything > > […] > are for the > > […] > though and > > […] > that patches > > […] > into finding > > […] > been merged > > […] > then analyze > > […] > as I'd like > > […] > can tests > > […] > code, with > > […] > making commits > > […] > unsubscribe, > > […] --- ## #29935 — Stanislav Malyshev — 2007-05-30T06:03:09+00:00 URL: https://externals.io/message/29846#29935 · In reply to: #29932 > 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. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #29933 — Steph Fox — 2007-05-30T06:03:49+00:00 URL: https://externals.io/message/29846#29933 · In reply to: #29931 Hey Lukas, > Also keep in mind that there are plenty of subprojects under cvs.php.net. > These tend to be a lot simpler on the branching/merging side. So maybe > these are good testing grounds to get some of the infrastructure for karma > management in place. And then once we start feeling comfortable with > things, then we are more prepared to move php internals over. Yep, that's a smart idea. Practically everyone working for php.net touches the manual at some point or another, so moving the manual across before the versioned codebase would provide a modicum of pre-training across the board :) - Steph --- ## #29934 — Rasmus Lerdorf — 2007-05-30T06:04:20+00:00 URL: https://externals.io/message/29846#29934 · In reply to: #29932 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" > To: "Rasmus Lerdorf" > Cc: "Wez Furlong" ; "Ilia Alshanetsky" > ; "Edin Kadribasic" ; "PHP Internals > List" > 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 > > > […] --- ## #29936 — William A. Rowe — 2007-05-30T06:17:25+00:00 URL: https://externals.io/message/29846#29936 · In reply to: #29935 Stanislav Malyshev wrote: > > […] > > 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. Would be nice if svn already had versioning for metadata, but otherwise it's not that hard to learn (there are even tricks to jump your live tree from a cvs checkout to an svn checkout, although a cvs diff/svn checkout and patch is usually simpler.) The ASF finally set a hard cutoff, and forced the hand. People adapted. In other works, "svn doesn't suck" :) It's just a slightly different tool. svn status is a huge improvement over cvs up to locate the diffs in your current checkout. svn 1.4 finally gives you the chance to mirror the repository. E.g. if you could do it in cvs, you can do it (somehow) finally in svn. The problem, as Rasmus points out, is that a huge repository like php's naturally doesn't migrate cleanly, and that's not even pointing out the nightmares of fat fingers crawling around rcs ,v files. --- ## #29937 — Steph Fox — 2007-05-30T06:18:29+00:00 URL: https://externals.io/message/29846#29937 · In reply to: #29935 Hi Stas, > 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. It's different if you're someone who doesn't really know what a CVS is and just uses the tool mechanically. That's probably most of the translation teams, some of the documentation teams, a fair proportion of the PEAR and smarty folk.... It's a new tool. Windows-based docs people need to use cygwin to generate a test build on their home pc, so it's a fair bet that most of them will be using commandline cvs without actually understanding it. For svn they'll all be downloading something else they don't really understand (or need to), but that's intimidating for doze people - usually downloading anything via cygwin means downloading about another 8 things that you've no idea about (dependencies). It's actually easier for the coding teams because they can just use tortoisesvn... Anyway this is 'future talk' so I'll stave off the panic for now :) - Steph --- ## #29941 — Marcus Boerger — 2007-05-30T07:45:41+00:00 URL: https://externals.io/message/29846#29941 · In reply to: #29934 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: > > […] Best regards, Marcus --- ## #29942 — Steph — 2007-05-30T07:48:06+00:00 URL: https://externals.io/message/29846#29942 · In reply to: #29941 > 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. Amen. - Steph --- ## #29943 — Rasmus Lerdorf — 2007-05-30T08:02:56+00:00 URL: https://externals.io/message/29846#29943 · In reply to: #29941 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: > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus --- ## #29945 — Steph Fox — 2007-05-30T08:19:26+00:00 URL: https://externals.io/message/29846#29945 · In reply to: #29943 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: > > […] --- ## #29947 — Rasmus Lerdorf — 2007-05-30T08:29:06+00:00 URL: https://externals.io/message/29846#29947 · In reply to: #29945 Steph Fox wrote: > 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. Well, the problem is that if the work involved to do this is in any way CVS-specific, it will be throw-away work once we move away from CVS, which is inevitable. What we don't know at this point is the lifespan of CVS. I'm unmotivated to do anything with SVN with the major 1.5 release coming up in a month or two. But if someone else is gung ho enough to volunteer sooner and has an eye on 1.5 to make sure the stuff will be compatible with the new release, perhaps things can move quicker. -Rasmus --- ## #29948 — Steph Fox — 2007-05-30T09:02:51+00:00 URL: https://externals.io/message/29846#29948 · In reply to: #29947 Rasmus, > > […] > > Well, the problem is that if the work involved to do this is in any way > CVS-specific, it will be throw-away work once we move away from CVS, > which is inevitable. I agree entirely - that's exactly what I meant by 'thinking through in svn terms as well as in cvs terms'. What we don't know at this point is the lifespan > of CVS. I'm unmotivated to do anything with SVN with the major 1.5 > release coming up in a month or two. But if someone else is gung ho > enough to volunteer sooner and has an eye on 1.5 to make sure the stuff > will be compatible with the new release, perhaps things can move quicker. Given that this entire thread came about because at least two of the core team don't have time to deal with merging to HEAD, that doesn't seem very likely. But you're right to put an end to quick-fix and possibly cvs-specific solutions. Does svn even support validation scripting? Does anyone even know without checking? Lukas was onto a good thing with his idea of moving less challenging areas of the CVS repository to SVN first IMHO. It'll make the task of moving the difficult ones less horrendous, and it'll give some idea of the problems likely to be encountered in adoption (if any). - Steph --- Next page: https://externals.io/message/29846.md?page=2