> > In one corner, we have Luke's event patch (#2759); in the other,
> > Brice's checksum => none patch (#2929). In the middle, the current
> > champion, the code from master.
>
> I've a good news for you. I removed from #2929 the patch that produces
> the conflict and isolated it in brice:ticket
On 19/03/10 23:41, Markus Roberts wrote:
> In one corner, we have Luke's event patch (#2759); in the other,
> Brice's checksum => none patch (#2929). In the middle, the current
> champion, the code from master.
I've a good news for you. I removed from #2929 the patch that produces
the conflict a
On 20/03/10 00:01, Luke Kanies wrote:
> On Mar 19, 2010, at 3:41 PM, Markus Roberts wrote:
>
>> In one corner, we have Luke's event patch (#2759); in the other,
>> Brice's checksum => none patch (#2929). In the middle, the current
>> champion, the code from master. So what should the final merge
Brice, would you and Peter be able to test this on the 0.25.x
version of the patch, and then I can make my recommended changes to
my events branch?
I'll test and try to give feedback on whatever comes up for 0.25.x.
I'm now running anyway on 0.25.x (with brice's and bryan's patches)
and I
On Mar 19, 2010, at 3:41 PM, Markus Roberts wrote:
In one corner, we have Luke's event patch (#2759); in the other,
Brice's checksum => none patch (#2929). In the middle, the current
champion, the code from master. So what should the final merged
result look like?
It's unfortunately not that
In one corner, we have Luke's event patch (#2759); in the other,
Brice's checksum => none patch (#2929). In the middle, the current
champion, the code from master. So what should the final merged
result look like?
<<<
def matching_edges(events, base = nil)
events.inject([]) do |m
