Re: Copy node vs copy property (was Re: CVS update ...)

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> > Since these are done by one trail (one DB transaction), the
> > order of above three operation doesn't matter. So you can
> > first create a new fs revision and then walk through mutable
> > nodes. When the function finds a mutable node, it checks
> > whether it is a copy node or not and if it is, it replaces
> > base fs revision field of copy property.
>
> Yes, that would certainly work. It's kind of ugly, though, for the
> filesystem to be wonking on node properties. It would be really nice
> if we could come up with an entirely client-side approach.

I'm a bit confused. What do you mean by entirey client-side
approach? Somehow the information where copy node has been
copied from must be stored in filesystem?

Can we decide which one to use, copy node or copy property?
Copy handling is another big thing left unimplemented in the
filesystem.

As I've said, I'm +1 for node property. But I'd like to
propose using flag field, instead of property field. Flag
field is internal to filesystem and it's unlikely to be as
crowded as property field will be.

-- 
Yoshiki Hayashi