Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45017
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 207.97.245.163 as permitted sender)
To: shire <shire@tekrat.com>
In-Reply-To: <4A5FBF41.8070400@tekrat.com>
References: <4A5FA493.9040204@lerdorf.com> <4A5FA8B2.1080102@sci.fi>	 <4A5FAD73.1060109@tekrat.com> <fe05d1540907161617xc78359eg4563ef817b7d0474@mail.gmail.com> <4A5FBF41.8070400@tekrat.com>
Message-ID: <B7E489A9-2F4F-4DBF-A620-9C00266F606B@php.net>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 17 Jul 2009 11:31:52 -0400
Cc: Pierre Joye <pierre.php@gmail.com>,
 jani.taskinen@iki.fi,
 Rasmus Lerdorf <rasmus@lerdorf.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Subject: Re: [PHP-DEV] svn checkout suggestion
From: davey@php.net (Davey Shafik)


On Jul 16, 2009, at 08:01 PM, shire wrote:

> 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 =20=

>>>>> pretty
>>>>> easily now and thus avoid multiple similar commits with annoying =20=

>>>>> MFH/MFB
>>>>> commit log messages that are hard to track.
>>>> I did a commit today on all 3 branches and it worked fine except =20=

>>>> for the
>>>> fact that no commit email was sent anywhere. I sent Gwynne a note =20=

>>>> 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 =20
>>> to merge
>>> our branches rather than duplicating commits or manually merging?  =20=

>>> I think
>>> this could speed up development and allow us to have more control =20=

>>> over
>>> releases, versions, etc.  I've seen cases in the past where =20
>>> changes fall
>>> through the cracks because they didn't get manually merged up/=20
>>> down.  The
>>> ability to merge complete branches as a branch rather than many =20
>>> 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 =20
> likely require us changing our current methodology for creating =20
> branches.  Currently we make a branch and never merge it back, this =20=

> is a bit different than what's seen in some other repositories.  =20
> Specifically, we'd need to look at creating more branches for =20
> specific features and merging those back to a central version or =20
> 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 =20=

> sure things get synced back and forth (probably a RM), but this can =20=

> be useful for keeping a development version relatively stable and =20
> encouraging cooperation between developers.  Once a release goes out =20=

> this stable code can then be merged back up-stream into the next =20
> major release or trunk etc.  Obviously there's lots of details in =20
> here about how it can be structured and work, but I'm mostly asking =20=

> about the high level "is this the direction we want to go".
>
> This would basically mean you could make as many single commits as =20
> necessary for whatever you're working from without adversely =20
> affecting a lot of other branches or having to make up multiple =20
> commits for each bug.  The downside being that to keep conflicts =20
> simple we should merge and merge often, and this could require the =20
> developer to do the "merge" on each commit or the RM doing a series =20=

> of them and resolving any possible commits themselves.  The first =20
> would be closer to what we do now, but would be simpler and allow =20
> merge-tracking.  Would be interesting to know how some other large =20
> FOSS projects are handling this as well and what those experiences =20
> have been like.  We also can't really do this for our current =20
> branches, it would probably need to be for all future versions.
>
> -shire

More importantly, the branch/merge support in SVN is limited to =20
temporary feature/bug branches. You branch, *complete* the feature/bug =20=

fix, and then merge it in. After that, if you decide to carry on in =20
your branch, SVN's merge tracking cannot handle the tracking of =20
changes. You need to merge, delete, re-branch, carry on. This doesn't =20=

work for say, the 5.3.x branch fixes getting pushed into trunk, the =20
5.3.x branch is toast as far as SVN is concerned once you merge the =20
first fix =97 quite useless.

- Davey