accumulo-dev mailing list archives

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

View raw message