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

Re: FSFS successor ID design draft

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 30 Aug 2011 15:25:18 -0400

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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-08-30 21:26:02 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.