Home | About | Sematext search-lucene.com search-hadoop.com
 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
Christopher 2013-06-12, 19:49
Re: "The lifetime of the v2 branch is then subject to the same
circumstance we've talked about previously."

Right, my only additional point was that we should be aware that it
may have a much longer lifetime, due to the fact that it doesn't make
sense to re-release/re-tag it when it doesn't appear to have any
changes (but its history would show a commit from the merge, and a
complementing commit that together are effectively a no-op). This
branch longevity in these circumstances may not be desirable, but we
should be aware of the possibility, so that the branch doesn't get
deleted and somebody down the road is expected to resolve the
conflict.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 11, 2013 at 8:46 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> On 06/11/2013 12:26 PM, Christopher wrote:
>>
>> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser<[EMAIL PROTECTED]>  wrote:
>>>
>>> >The person who implements the workaround in Version1 should ensure that
>>> > when
>>> >Version1 is merged into Version2, the correct code is present in
>>> > Version2.
>>
>> I'm not sure that's a sufficient solution, because this means that the
>> branch for Version2 may stick around with effectively no change from
>> its last tag other than history, and you can't simply update the tag
>> to update the history, can you? Either it sticks around for a very
>> long time, or it goes away and eventually somebody else is going to
>> have to resolve that potential merge conflict when fixing the next bug
>> that comes around (which maybe applies to both).
>>
>
> I think I already addressed this concern with Mike later in this thread, but
> I'll restate for completeness:
>
> Even if a merge from v1 to v2 is a no-op in terms of changes, the fact that
> a non-no-op change in v1 merits a no-op change in v2 is important, and thus
> this is important for the developer to record with a merge.
>
> The lifetime of the v2 branch is then subject to the same circumstance we've
> talked about previously.