Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo, mail # dev - [git] Documentation and Plan of Action


+
Josh Elser 2013-06-05, 03:04
+
Josh Elser 2013-06-06, 01:58
+
Josh Elser 2013-06-11, 02:44
+
Sean Busbey 2013-06-11, 11:16
+
Josh Elser 2013-06-11, 12:55
+
Mike Drob 2013-06-11, 15:44
+
Josh Elser 2013-06-11, 16:05
+
Christopher 2013-06-11, 16:26
+
Josh Elser 2013-06-12, 00:46
+
Christopher 2013-06-12, 19:49
+
David Medinets 2013-06-13, 02:45
+
Christopher 2013-06-13, 04:21
+
Josh Elser 2013-06-13, 02:59
+
Mike Drob 2013-06-11, 23:10
+
Josh Elser 2013-06-11, 23:18
+
Mike Drob 2013-06-11, 23:25
+
Josh Elser 2013-06-11, 23:39
+
Christopher 2013-06-12, 20:21
+
Josh Elser 2013-06-12, 22:15
+
Christopher 2013-06-12, 23:09
+
Drew Farris 2013-06-13, 01:05
+
Josh Elser 2013-06-13, 01:16
Copy link to this message
-
Re: [git] Documentation and Plan of Action
David Medinets 2013-06-13, 02:48
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
>>
>>
>
+
Josh Elser 2013-06-13, 02:52
+
Drew Farris 2013-06-13, 01:38
+
Josh Elser 2013-06-13, 02:00
+
Josh Elser 2013-06-13, 03:23
+
Christopher 2013-06-13, 05:16
+
John Vines 2013-06-13, 17:36
+
Christopher 2013-06-13, 17:49
+
John Vines 2013-06-13, 17:55
+
Corey Nolet 2013-06-13, 20:26
+
Josh Elser 2013-06-13, 23:54
+
Josh Elser 2013-06-13, 23:52
+
Eric Newton 2013-06-12, 22:52
+
Christopher 2013-06-12, 21:35