accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [git] Documentation and Plan of Action
Date Thu, 13 Jun 2013 01:16:48 GMT
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
>


Mime
View raw message