bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unionmount. Basic details


From: Sergiu Ivanov
Subject: Re: Unionmount. Basic details
Date: Mon, 27 Apr 2009 21:40:58 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)

Hello,

<olafBuddenhagen@gmx.net> writes:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
>> Carl Fredrik Hammar <hammy.lite@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]