Hello, <olafbuddenha...@gmx.net> writes: > On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote: >> Carl Fredrik Hammar <hammy.l...@gmail.com> writes: > >> > Well it isn't simpler in the sense that we'd need to maintain two >> > very similar yet different code bases. Improvements to one would >> > likely get ported to the other. > [...] >> Also, I'm not aware of anybody still doing any changes to unionfs :-) > > This doesn't preclude the possibility that while working on unionmount, > you find improvments to the merging code, that can be applied to unionfs > as well... But it should be easy to cherry-picking the changes, if the > fork is properly recorded in revision control -- so I don't see that as > a major problem.
Yes, true, I actually suppose that I will make such changes to unionfs code base that could be useful in unionfs itself: for instance, unionfs is still read-only; and I'd like to see unionmount with complete read/write functionality. And I agree with you that it shouldn't be too hard to move these changes to the original unionfs. >> I still cannot see why having a shadow-node server is better than >> creating the shadow nodes in-process. Note that creating a new server >> will involve creating a new interface, which I'm inclined to consider >> a little bit of overkill... > > Creating a new interface is not a problem per se. It's the complexity of > the required interaction that bothers me. Yes, I really wanted to say this, but somehow failed. Regards, scolobb
