[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2001-03-12 14:11:09 CET

On Fri, Mar 09, 2001 at 04:06:42PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > 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.
>
> Why couldn't the client clear it... ooooh, icky. Hmmm.
>
> [Karl, in the third person, decides to punt on this for a while, being
> occupied with other things. Agrees we need to solve it. Is content
> to let it sit and rot for now, though.]
>
I thought we had decided that the copy property could include
information about when it was copied. Thus the property wouldn't need
to be deleted, it could live indefinitely. (I.e.), Property says
something like revision 11.2 of this node is a copy of revision 12.3.

Then the property itself distinguishes which revision the copy occurred
in.

Am I missing something?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:25 2006

This is an archived mail posted to the Subversion Dev mailing list.