Greg Stein <[email protected]> writes: > On Wed, Mar 24, 2010 at 16:41, Philip Martin <[email protected]> > wrote: >> neels <[email protected]> writes: >>> On 23 March 2010 09:11, Greg Stein <[email protected]> wrote: >>>> On Mon, Mar 22, 2010 at 17:59, Philip Martin <[email protected]> >>>> wrote: >> >> We should consider using copyfrom_repos_path. The current method of >> only storing copyfrom_* on the root of the copy means that >> copyfrom_repos_path needs to be calculated every time its value is >> required. > > 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. >> The other copyfrom_* fields contain the same value through >> the copy, so it makes sense to elide those where possible. We could >> use something like: >> >> copyfrom_repos_id == NULL copyfrom_repos_path == NULL : added, no copy >> copyfrom_repos_id != NULL copyfrom_repos_path != NULL : root of copy/move >> copyfrom_repos_id == NULL copyfrom_repos_path != NULL : child of copy/move > > Not sure about this. > >>> May I suggest to use the WORKING node's 'presence', as we already do >>> with subpath deletions inside copied trees. A presence of >>> 'not-present' currently indicates that a subpath of a recursive copy >>> is excluded from the copy, IOW that it is the root of a delete >>> operation inside a copy. A new value called 'not-related' could >>> indicate that a path is the root of an *add* operation that is not >>> related to the add operation of its parent. >> >> 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. > This will solve the "add into another operation's tree", but it does > not solve the "did I replace a node in that tree? thus, do I need to > issue a DELETE before issuing this new operation?" > > Having a "root" presence also means we can easily scan upwards for the > base of an operation. Hmm. Tho I guess the base of a deletion wouldn't > be marked root... -- Philip
