Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> 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?
What I meant is that the client can accomplish the task using only the
existing svn_fs.h interface. The filesystem can remain simple and
ignorant of copy tracking, while the client takes care of annotating
things appropriately.
Received on Sat Oct 21 14:36:25 2006