Greg Stein <gstein@lyra.org> writes:
> On Fri, Mar 09, 2001 at 08:39:55AM -0600, Karl Fogel wrote:
> > Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> > > 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?
> >
> > I believe Jim means that
> >
> > $ svn copy foo.c bar.c
> >
> > adds a copy property to bar.c, so that when bar.c is committed, it
> > simply _has_ the requisite property without the fs doing any extra
> > work. I.e., for the fs, the copy properties would be read-only data.
> > The source would always be the client.
>
> If it is a property that was (effectively) placed on node ID 11.2, then how
> do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
> assistance from the server (to clear copy props), we couldn't get that prop
> cleared on the successor.
As I said before, if the property's value can somehow be marked with
the revision in which the copy was made, there's no ambiguity. The
property can persist, but we always know when the event happened.
The problem is that the property is set as part of a transaction, but
a client of the svn_fs.h interface has no idea what the revision
number will be until the transaction has been committed. So there's a
small chicken-and-egg problem. But it doesn't seem fundamental, so
I've been hoping someone would come up with a clever way around it.
Received on Sat Oct 21 14:36:25 2006