Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Backporting policy proposal


Copy link to this message
-
Re: Backporting policy proposal

On 6/18/13 11:26 AM, Adam Fuchs wrote:
> On Jun 18, 2013 11:05 AM, "Josh Elser" <[EMAIL PROTECTED]> wrote:
>>
>> On 6/18/13 10:53 AM, Adam Fuchs wrote:
>>>>
>>>>>
>>>>> 2. Back-porting performance improvements to a prior release line that
>>>>> is not EOL (end-of-life) is usually okay (subject to normal lazy
>>>>> consensus), so long as it does not change user-facing behavior or API.
>>>>> It is still strongly preferred to add such fixes in the older branch
>>>>> first, and merge forward to the newer one(s).
>>>
>>> Agree, although doesn't the transition to git alleviate the problems with
>>> order of operations?
>>>
>>
>> I don't understand what you mean by "order of operations". If you push a
> commit in 1.6.0-SNAPSHOT that should really be in 1.4.4-SNAPSHOT, Git will
> not handle this well in terms of an accurate history.
>
> I don't really understand either -- that was mostly speculation. Doesn't
> the reliance on hashes of the patch rather than commit IDs make it
> immaterial as to which branch a patch was committed to first? Admitedly, I
> am not an expert on git.
>
> Adam
>

No, that's incorrect. A commit is uniquely identified by a set of
attributes which, most importantly, include the parent commit. As such,
what you would have typically (happily) done with subversion (`svn merge
-r 12345 .`) has implications to the Git history graph.

The only way to accomplish this in Git is to cherry-pick that commit
which causes multiple unique commits which apply the same changes to
content. This also makes using tools like `git-bisect` much less
effective as a bug introduced in a cherry-pick'ed commit now has
multiple points of introduction instead of a single commit.

In the downtime before we hear back from INFRA, it would be good to read
through the documentation: http://git-scm.com/documentation
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB