Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
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
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB