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