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 >> [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
The point is that any developer, at any point in time (sans mid-merge of
another developer), should be able to cleanly merge from 1.x->1.y. This
is the same policy as we follow with SVN currently

`cd accumulo-1.y`
`svn merge -r 1:HEAD 1.x .`

Sometimes there are funny things that happen with drastically different
new features/implementations, but this is expected with an active
project over time.

On 06/12/2013 10:48 PM, David Medinets wrote:
> Why would you apply a change specifically for 1.4.4 to 1.5 code? The change
> simply does not apply.
>
>
> On Wed, Jun 12, 2013 at 9:16 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
>> On 06/12/2013 09:05 PM, Drew Farris wrote:
>>
>>> Josh, Chris, Mike, thanks for hashing this out. The document is long, but
>>> I
>>> believe it contains the appreciate level of detail so as to eliminate
>>> many ambiguities/questions as to how things are done.
>>>
>>> I have a couple questions. From the docs:
>>>
>>> " Whatever the actual case is, the developer who made the first set of
>>> changes (you) is the one responsible for performing the merge through the
>>> rest of the active versions. Even when the merge may results in a
>>> zero-length change in content, this is incredibly important to record as
>>> you are the one who knows that this zero-length change in content is
>>> correct!"
>>>
>>> Sorry for the newb question, but how does one actually create zero length
>>> commit?
>>>
>> Take the loggers for example. In 1.4, we have local disk loggers, and in
>> 1.5, HDFS loggers. Hypothetically, say there is additional work on the
>> internal Logger interface that is only required on local disk loggers and
>> not HDFS loggers, let's call this method "foo()" on Logger.
>>
>> In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in
>> which you need to call Logger.foo(). You complete the changes and
>> 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your
>> change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer
>> required because it's natively handled by the HDFS Logger implementation.
>>
>> This is a (contrived) example of how a change in a lower version may be
>> OBE in more recent versions. Does that make sense?
>>
>>
>>   Also, I have encountered cases where a merge has pulled in changes from
>>> previous branches that were unrelated to the particular changes I am
>>> trying
>>> to merge upwards. I suspect this has something to do with the fact that
>>> someone else has done something wrong (eg: neglected to merge their
>>> change). What is the appropriate approach to resolving this issue?
>>>
>> Yes, this, ideally, should never happen. It is always possible that you
>> get merge conflicts in the target version due to changes upstream
>> (1.5.1-SNAPSHOT) that were not applied downstream (1.4.4-SNAPSHOT). The dev
>> merging their changes should alleviate most of this; however, it is not
>> foolproof. In this case, it would be on you to resolve the conflict as even
>> though it was not your changes alone that created the conflict your changes
>> were the most recent. It would also be reasonable to expect the other dev
>> to also help you with the conflict :)
>>
>>> Drew
>>>
>>>
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