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 >> >> >
