Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45008
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekrat.com from 208.43.138.18 cause and error)
Message-ID: <4A5FBF41.8070400@tekrat.com>
Date: Thu, 16 Jul 2009 17:01:05 -0700
User-Agent: Postbox 1.0b13 (Macintosh/2009062916)
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: jani.taskinen@iki.fi, Rasmus Lerdorf <rasmus@lerdorf.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <4A5FA493.9040204@lerdorf.com> <4A5FA8B2.1080102@sci.fi>	 <4A5FAD73.1060109@tekrat.com> <fe05d1540907161617xc78359eg4563ef817b7d0474@mail.gmail.com>
In-Reply-To: <fe05d1540907161617xc78359eg4563ef817b7d0474@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] svn checkout suggestion
From: shire@tekrat.com (shire)

Pierre Joye wrote:
> On Fri, Jul 17, 2009 at 12:45 AM, shire<shire@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