Pierre Joye wrote:
On Fri, Jul 17, 2009 at 12:45 AM, shire<sh...@tekrat.com> wrote:
Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3 branches and it worked fine except for the
fact that no commit email was sent anywhere. I sent Gwynne a note about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..
Do we have a long-term plan of using actual merge commands/tools to merge
our branches rather than duplicating commits or manually merging? I think
this could speed up development and allow us to have more control over
releases, versions, etc. I've seen cases in the past where changes fall
through the cracks because they didn't get manually merged up/down. The
ability to merge complete branches as a branch rather than many different
commits could save some hastle assuming everyone follows the same
commit/merge patterns.
I doubt any tools can really help to automatically help to merge
changes from one branch to another (in php). However there are many
very good merging tools (with UI) out there to ease this process
(meld, winmerge, etc.).
I don't see why this wouldn't be possible for PHP, but it would likely require
us changing our current methodology for creating branches. Currently we make a
branch and never merge it back, this is a bit different than what's seen in
some other repositories. Specifically, we'd need to look at creating more
branches for specific features and merging those back to a central version or
trunk depending on the release it's planned to go out with.
One downside to this is that you usually need to have someone making sure things get
synced back and forth (probably a RM), but this can be useful for keeping a development
version relatively stable and encouraging cooperation between developers. Once a release
goes out this stable code can then be merged back up-stream into the next major release
or trunk etc. Obviously there's lots of details in here about how it can be structured
and work, but I'm mostly asking about the high level "is this the direction we want
to go".
This would basically mean you could make as many single commits as necessary for whatever
you're working from without adversely affecting a lot of other branches or having to make
up multiple commits for each bug. The downside being that to keep conflicts simple we
should merge and merge often, and this could require the developer to do the
"merge" on each commit or the RM doing a series of them and resolving any
possible commits themselves. The first would be closer to what we do now, but would be
simpler and allow merge-tracking. Would be interesting to know how some other large FOSS
projects are handling this as well and what those experiences have been like. We also
can't really do this for our current branches, it would probably need to be for all
future versions.
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
