You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/05/21 14:42:27 UTC

Re: svn commit: r658105 - in /apr/apr/trunk: CHANGES shmem/win32/shm.c

mturk@apache.org wrote:
> @@ -1,6 +1,10 @@
>                                                       -*- coding: utf-8 -*-
>  Changes for APR 1.4.0
>  
> +  *) Make sure WIN32 behaves the same as posix for file backed
> +     shared memory by removing the file on cleanup/remove.
> +     [Mladen Turk]
> +

This is pretty weird, you marked this as an APR 1.4.0 change and then
backported the behavior to 1.2 and 1.3 ... huh?

Re: svn commit: r658105 - in /apr/apr/trunk: CHANGES shmem/win32/shm.c

Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> mturk@apache.org wrote:
>> @@ -1,6 +1,10 @@
>>                                                       -*- coding: 
>> utf-8 -*-
>>  Changes for APR 1.4.0
>>  
>> +  *) Make sure WIN32 behaves the same as posix for file backed
>> +     shared memory by removing the file on cleanup/remove.
>> +     [Mladen Turk]
>> +
> 
> This is pretty weird, you marked this as an APR 1.4.0 change and then
> backported the behavior to 1.2 and 1.3 ... huh?
> 

Well the intention wasn't to mark it as 1.4 (trunk) change.
The purpose was to mark the version from which the API
implementation is fixed, so I suppose I should backport this
note to 1.2.x and 1.3.x as well.

Regards
-- 
^(TM)

Re: svn commit: r658105 - in /apr/apr/trunk: CHANGES shmem/win32/shm.c

Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> mturk@apache.org wrote:
>> @@ -1,6 +1,10 @@
>>                                                       -*- coding: 
>> utf-8 -*-
>>  Changes for APR 1.4.0
>>  
>> +  *) Make sure WIN32 behaves the same as posix for file backed
>> +     shared memory by removing the file on cleanup/remove.
>> +     [Mladen Turk]
>> +
> 
> This is pretty weird, you marked this as an APR 1.4.0 change and then
> backported the behavior to 1.2 and 1.3 ... huh?
> 

Well the intention wasn't to mark it as 1.4 (trunk) change.
The purpose was to mark the version from which the API
implementation is fixed, so I suppose I should backport this
note to 1.2.x and 1.3.x as well.

Regards
-- 
^(TM)