[infinispan-dev] CacheDelegate.lock() strangely differing between trunk and 4.2.x

Sanne Grinovero sanne.grinovero at gmail.com
Wed Sep 15 14:31:05 EDT 2010


2010/9/15 Galder Zamarreño <galder at redhat.com>:
> Indeed, I've reopened https://jira.jboss.org/browse/ISPN-641 and https://jira.jboss.org/browse/ISPN-642 cos Sanne hasn't got around to putting this fixes in trunk yet and I don't want us end up missing them.

Sorry for that, I think I've misunderstood the directions given on the
mailing list regarding the 4.1 to 4.2 patches; In the 4.1.x era it was
clear to me that I needed to apply all patches of 4.1.x to trunk as
well, but thought I didn't need to do so for 4.2.
Galder, thanks for spotting that and warning me; I'm fixing it right now.

I'm still a bit confused about this practice, shouldn't we apply the
patches to a single branch and bring them to trunk using svn merge?
Just wondering.

Sanne

>
> On Sep 15, 2010, at 12:17 PM, Manik Surtani wrote:
>
>> Guys if we have closed JIRAs in 4.2.x we *must* apply these to trunk as well.  This is just the start of the kind of problems we're going to experience if we don't stick to this simple rule.
>>
>> On 15 Sep 2010, at 10:43, Galder Zamarreño wrote:
>>
>>> Hi Mircea,
>>>
>>> There's something that's causing me issues in the CacheDelegate code. There're some differences between trunk and 4.2.x which I don't understand:
>>>
>>> In trunk you find:
>>>
>>>  public void lock(K key) {
>>>     assertKeyNotNull(key);
>>>     //this will be removed with https://jira.jboss.org/browse/ISPN-598
>>>     ConfigurationValidatingVisitor.checkEagerLockingAndDld(config, true);
>>>     lock(Collections.singletonList(key));
>>>  }
>>>
>>> And in 4.2.x:
>>>
>>>  public void lock(K key) {
>>>     assertKeyNotNull(key);
>>>     lock(Collections.singletonList(key));
>>>  }
>>>
>>> First of all, that comment about https://jira.jboss.org/browse/ISPN-598 is probably mixed up. I think it refers to https://jira.jboss.org/browse/ISPN-589 instead.
>>>
>>> Now, https://jira.jboss.org/browse/ISPN-589 has already been fixed. So, are those two lines some leftover due to merge mixup? Or do they really make sense to be there?
>>>
>>> The reason this is causing me issues is due to a patch I was trying to apply in trunk wrt https://jira.jboss.org/browse/ISPN-649.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list