On Jul 16, 2009, at 08:01 PM, shire wrote:
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
More importantly, the branch/merge support in SVN is limited to
temporary feature/bug branches. You branch, *complete* the feature/bug
fix, and then merge it in. After that, if you decide to carry on in
your branch, SVN's merge tracking cannot handle the tracking of
changes. You need to merge, delete, re-branch, carry on. This doesn't
work for say, the 5.3.x branch fixes getting pushed into trunk, the
5.3.x branch is toast as far as SVN is concerned once you merge the
first fix — quite useless.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
