On 4/28/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> Information storage
>
> The first question that many people ask is "where should we store the
> merge information" (what we store will be covered next).
>
> After a large amount of research, the design I have come up with is
> this:
> A merge info property, named SVN_MERGE_PROPERTY (not the real name, I
> have made it a constant so we can have a large bikeshed about what to
> really call it) stored in the revision properties, directory properties,
> and file properties.
> Each will store the *full, complete* list of current merged in changes,
> as far as it knows. This ensures that the merge algorithm and other
> consumers do not have to walk back revisions in order to get the
> transitive closure of the revision list.
>
> The way we choose which of file, dir, revprop merge info to use in case
> of conflicts simple system of inheritance[1] where the "most specific"
> place wins. This means that if the property is set on a file, that
> completely overrides the directory and revision level properties.
(Some questions were asked on IRC, so I'll try to replicate the
answers here, DannyB will hopefully correct me if I"ve screwed them up
too badly.)
Note that the answer of which is the "most specific place" needs to be
calculated more than once, for example if you've got merge props on
both dir A and dir A/B, then stuff under dir A/B uses A/B's merge
props and other things use dir A's. Note that this implies that later
merges to A need to update A/B's props.
> The way we choose which to store to depends on how much and where you
> merge, and will be covered in the semantics.
>
> The reasoning for this system is to avoid having to either copy info
> everywhere, or crawl everywhere, in order to determine which revisions
> have been applied. At the same time, we want to be space and time
> efficient, so we can't just store the entire revision list everywhere.
Note that in order for having revprops used for storage actually
become more efficient you need to assume that merge calculations are
being done server side, and thus have quick access to all the
revprops. If the calculation happens client side obviously dropping
revprops is a win.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 28 19:12:37 2006