On Tue, Sep 23, 2014 at 12:31 PM, Stefan Fuhrmann < stefan.fuhrm...@wandisco.com> wrote:
> > On Thu, Sep 18, 2014 at 3:00 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > >> On 11 September 2014 20:28, Stefan Fuhrmann >> <stefan.fuhrm...@wandisco.com> wrote: >> > On Wed, Sep 10, 2014 at 5:35 PM, Ivan Zhakov <i...@visualsvn.com> >> wrote: >> > >> 2. Remove it since "named atomics" framework is only used for currently >> >> disabled revprop caching. >> > >> > >> > ... I'm +1 on getting rid of the SHM code altogether (we are using MMAP >> to >> > get shared memory). It turned out to be a poor choice as all sorts of >> > Windows >> > platform specifics make it hard caused us to deviate further and further >> > from >> > the initial APR-based design. Some of the Windows-specific issues, e.g. >> the >> > file retry races in the init code, should have been reported before the >> > 1.8.0 >> > release. >> > >> >> >> >> Personally I don't see reason to spend resources fixing unused code, >> >> especially >> >> that even code on 'revprop-caching-ng' branch removes it also. Any >> >> other opinions? >> > >> > >> > No, I agree. >> > >> > The revpro-caching-ng branch pretty much exactly removes the SHM >> > code. >> I think that the revprop-caching-ng branch should not be merged. So >> may be worth to remove named-atomics and SHM code from trunk to turn >> the trunk back to the normal state (without unused and not working code) >> > > Here is what I will do on /trunk: > > * Merge the new revprop caching scheme to FSX. > Done in r1632907,-9. * Remove the SHM-dependent bits from FSFS but keep the actual > cache invocations (no-ops since there is no cache instance) at least > for now. > Done in r1632926. * Remove the named_atomics code. > Done in r1632936. > * Update the revprop-caching-ng branch > Done in r1632945. > Why do you think the revprop-caching-ng branch should not be merged? > > -- Stefan^2. >
