On Fri, Mar 12, 2010 at 06:28, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: > >> The SUBDIR is a child of DIR in r9, and presumably also r6. When the >> commit is performed, constructing r10, SUBDIR is deleted. The working >> copy lists DIR at r9 which is *supposed* to include SUBDIR. Yet, due >> to mixed-rev working copies, we have SUBDIR at r10 which does not >> exist. It is therefore labeled as not-present. > > I disagree with "we have SUBDIR at r10". We expect SUBDIR at r9 but > the SUBDIR is not-present, its revision doesn't have a meaning. > >> By r23, it is possible for SUBDIR to return. >> >> If the parent is updated to r10, then the not-present SUBDIR can be >> removed because d...@10 does not list SUBDIR as a child. > > I think not-present nodes get removed on update irrespective of > revision. > >> The revision is quite necessary. > > All that you have written just requires SUBDIR not-present, it doesn't > require r10. > > Suppose the commit that deletes SUBDIR is r11 and the parent is r9. > When the parent gets updated, be it to r9, r10, r11 or r12 the > not-present node gets removed (and possibly replaced by a normal > node). The r11 revision doesn't matter.
.... yeah, I think I agree with all this. Thanks for the insight. I spent some time pondering on it today, and started to wonder whether this applies to "excluded" and "absent" nodes, too (all three are basically "the node isn't really there"). However, a node could be absent in a specific revision, yet available for other revs. (e.g. administratively hide the one rev which has a password in it) Excluded doesn't really need a revision. "Whatever it is, this node is being kept out of the working copy." We can't just wipe them before an update (like the not-present nodes) because the concept is sticky. I'm not entirely sure we should be removing not-present nodes before an update (conceptually). There may be a better design that results in the same thing, but from a better/cleaner direction. Lastly... we may want to enforce this notion of "no revision", and have base_get_info() and read_info() return SVN_INVALID_REVNUM for not-present nodes (and excluded nodes). Then again, I think of Daniel's work on revision_status() lately. If I do: $ svn rm path/subdir $ svn commit path/subdir $ svnversion Should it report "just r9", or should it report "r9-10" ? I kind of think the latter, but if not-present nodes have no revision, then this working copy would be JUST r9. But that isn't true either. subdir is missing. >> This post-commit bumping of the SUBDIR revision and marking it as >> not-present is part of the commit processing. It should happen during >> the queue work, rather than a special pass. This bumping/marking is >> *required* by our mixed-rev design, and needs to stick around. > > Agreed. > >> Thus, >> it should be integrated into the database manipulation for the commit >> handling of SUBDIR. >> >> I'm saying: remove the special handling today, and do it as part of >> the normal commit process. Do that today, because we also need it >> tomorrow. > > Perhaps. As part of the move to a singe db we have to make "ordinary" > directory deletion work without using the .svn directory in the > deleted directory. We might take advantage of the single db to do > this. When ordinary deletion works the special case code can simply > be deleted. Removing the special case code before single db might be > more complicated, or it might be a step along the way. It depends on > the details of the implementation. Yes. My gut says that our commit process needs to consider and handle this case. Thus, to get our commit handling for wc-ng done, we need the case relocated to that point (svn_wc__db_global_commit). Single or multi-db... it doesn't feel like the coding will be any different, but I do think that having it co-located will help global_commit(). Cheers, -g
