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
