Home | About | Sematext search-lucene.com search-hadoop.com
 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
>>>
>>>