Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.193 as permitted sender)
Message-ID: <4E40206C.1060301@sugarcrm.com>
Date: Mon, 08 Aug 2011 10:44:12 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <slrnj3tulc.6vi.dsp@experimentalworks.net> <1312821297.1485.171.camel@guybrush>
In-Reply-To: <1312821297.1485.171.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Choosing a distributed version control system
 for PHP (or not). Call for Participation.
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

On 8/8/11 9:34 AM, Johannes Schlüter wrote:
>        * It is said that the preferred way to get a patch from one branch
>          to another is by doing a merge operation in the VCS. Depending
>          on the timing we will most likely end up with two (trunk + 5.4)
>          or, more likely, three (+ 5.3) old branches which are active.
>          Will it be possible to merge between them using the VCS's merge
>          facilities or will we end up cherry-picking there? If this is

Depending on the direction of merges, it may work as merge (if you want 
all changes, i.e. merging up) or as cherry-pick (if you want to merge 
down). Or you may make a branch from your changes and merge it where you 
like.
What's good with cherry-picking, you can still have full commits so you 
know who did it and why and can relate to the original source.

>          possible and we continuously merge these branches what are the
>          strategies for preventing specific changes from being merged
>          with the suggested systems (git and hg)?

I'd suggest putting changes always in the lowest (oldest) branch first 
and then merge the branches up to newest. This way we ensure the changes 
are always in sync. But there can be challenges if there is substantial 
code change between branches, of course, so sometimes we'd have to 
cherry-pick or even do something more interactive, git merge is good but 
not *that* good :)

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227