On Wed, Mar 31, 2010 at 05:19, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: >... >> I doubt that we use it independently of the other fields, so scanning >> upwards for the others can also compute the relpath. >> >> We do the same thing for the regular repos_id and repos_relpath. > > I see there is a comment to that effect in wc-metadata.sql so perhaps > that was the intent, but in practice repos_id and repos_relpath appear > to be set in every base_node.
Yes. That isn't intentional, but is a current artifact of the implementation. >... >>> I suppose we could, but I think we already have enough storage for >>> this problem. If we were to adopt a new presence I think I'd make the >>> copied child have the new value. Nodes that are simple adds are very >>> similar to nodes that are the root of a copy: both represent new items >>> in the repository and it seems reasonable that they have the same >>> presence value. Copied children are the ones that are special or >>> different. >> >> Children of copies/moves/adds are all about the same. > > I'd disagree. > >> I think it is >> the root that stands out, especially because it is *that* node where >> we store the copy/move information. Thus, I would suggest a presence >> named "root" or "oproot" (operation root). > > Yes, roots stand out. But plain adds are like roots: they show up in > status, they need to be explicitly reported during a commit, they can > be reverted. Children of adds are themselves adds and are thus roots. > It's the children of copies/moves that are different, they are not > roots, their presence is implied by the presence of the parent. After pondering... yup. I'd agree. And note that deletes are similar -- the children do not need to be reported/acted-upon separately from the parent operation. >... It is also near time for us to pick a solution here. I just had to mark several tests as XFail() specifically because we cannot represent an "add" within a copied subtree. I would prefer a presence marker over "tricky interpretation" of the copyfrom_* fields. I believe that we have the following operations: add: plain old add add-within-copy/move: add within a subtree replace: delete-base + add replace-within-copy/move: delete-child + add delete-base: deleting a base node delete-child: deleting a child of an add/copy/move copy(-within): same as add• moved-here(-within): same as add* moved-away(-within): same as delete* I think the last three are the same as other stuff (meaning: no consideration needed), but with some extra markers. I'm thinking that we add the following presence values (for WORKING_NODE.presence): "added": same as "normal" today. clarifies what this really means. we map this to status_added, so why not use this for the presence anyways? no need to "minimize/conserve" the set of presence values. "replaced": indicates an added/copied-here/moved-here node that replaces a child of a copied-here/moved-here subtree. "deleted": same as "not-present" today. clarifies what this really means. "inherit": applied to children of copied-here/moved-here and deleted/base-deleted nodes. implies that no commit operations are required for these nodes. The APIs from wc_db should remain the same. This is a database-only change. The concepts are surfaced through read_info(), scan_addition(), and scan_deletion() as before. Thoughts welcome. There is no particular rush on this, but I'd hope to complete it in the next few weeks. This change will require a format bump, which I would perform *before* the props-in-database change (which still has db-state inconsistency problems to work through). Cheers, -g
