On Tue, 2011-08-30, C. Michael Pilato wrote:
> On 08/30/2011 12:34 PM, Hyrum K Wright wrote:
> >> There is at most one successor on the same line of history (same copy_id).
> >> Each copy operation also creates one new successor.
> >
> > I think we need to be bit more clear about when a successor is
> > actually created in the case of copy. For most copies, particularly
> > those of the recursive directory kind, a new successor isn't created
> > until we write to the node. This has some interesting implications.
> >
> > For instance, folks usually don't modify the contents of a tag, so
> > there wouldn't be any successor link created for the tag contents.
> > Even though the tag contents are "logical" successor of their source
> > files, they aren't actually stored as such. Doing so would make
> > copying a O(N) operation instead of O(1). (Of course, the O(1)
> > behavior gives incomplete results when asking "where did this bug move
> > to?")
So, IIUC, to answer the "Where did this bug move to?" question
correctly, we need to examine the successors of each parent directory of
the file in question as well as of the file itself. That sounds totally
fine.
- Julian
> > Mike may have already worked most of this out on the BDB branch.
>
> Sure, the BDB code adds successors only where it also would add precessors.
> If you create a tag, you create a copy of some directory. That copy has a
> predecessor "link" back to the directory it was copied from; the directory
> it was copied from as a successor "link" to the new tag.
Received on 2011-08-31 12:04:19 CEST