On Wed, Mar 14, 2001 at 12:39:51PM -0500, Jim Blandy wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > > In short, you also add fs revision number to property which
> > > indicates when it is copied.
> >
> > It occurs to me that a node-revision can only be a copy of its
> > immediate predecessor. Storing the path/rev of the revision copied
> > from provides enough information to determine the copy history of a
> > node, even if you leave the properties around indefinitely.
> >
> > (In other words, 100.3 can be a copy of some rev/path which refers to
> > 100.2, but successors of 100.3 cannot be a copy of the same rev/path,
> > since a copy of the same rev/path would become 100.2.1.1 or some other
> > successor of 100.2.)
>
> Ah hah! As I said, I was waiting for someone to be clever.
>
> So, when we find some node revision C with a copy property (REV,
> PATH), then we look up PATH in REV to find the original, some node
> revision O. If C is not an immediate successor of O, then the copy
> property doesn't apply to C.
I'm not sure if I'm reading this right... whether you're saying we can't...
but we *do* need to make copies of things other than "current". For example,
the tree could be at rev 103, but I want to revive a deleted subtree from
rev 22.
In the above example, why would 100.3 be created? Can't I just make a copy
without change? How would that work in this case?
Hmm. Is 100.3 created because we need to attach the copy property to it?
That makes sense. No other changes, right?
Ah... and 100.2 could actually be (22, /a/b/foo), right?
Me thinks me gots it. (and pls correct me if wrong)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:25 2006