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?") > > 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. > In reading through this, as well as the discussion in IRC, I'm once > again wondering why we're bolting this stuff onto the outside of FSFS > rather than rethinking the entire FS problem (along with things like > obliterate and move-to storage and ...). You and me both, brother. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
