Re: better changeset tracking
| From: | Steph Fox | Date: | Wed, 30 May 2007 09:02:51 +0000 |
| Subject: | Re: better changeset tracking | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-29948@lists.php.net to get a copy of this message | ||
Rasmus,
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 lifespanWe'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.
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