accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <>
Subject Re: [git] Documentation and Plan of Action
Date Thu, 13 Jun 2013 02:48:23 GMT
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 <> 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 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 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message