Pulling out this old email. I kept it marked because I think it may highlight a problem in the schema.
On Fri, Jan 29, 2010 at 09:36, Philip Martin <[email protected]> wrote: > "Bert Huijben" <[email protected]> writes: > >> * svn cp/mv/add/rm >> These commands look at the current version of the working copy >> (Based on BASE overlayed with WORKING) and apply changes to >> WORKING. (And update your working copy and ACTUAL with' relevant >> changes') > > How about the scenario in the other thread. I copy a directory > containing files: the new items have WORKING nodes but no BASE nodes. > That's what happens at present and it seems to be correct. Correct. > Now I delete one of the copied files; what should happen is that the > WORKING node gets modified to have WORKING.presence=not-present and > there is still no BASE node. That's not quite what happens at present > and it appears to be a bug. That is the intent. As Bert said, if that isn't what is happening (is there a BASE node? is WORKING not marked right?), then it is definitely a bug. What is the cause? Dunno. > What happens if I add something to replace the deleted file? Does the > WORKING node somehow record both the original copy and the new add? > There doesn't seem to be enough information stored: how would it cope > with the node kind changing for example? Here is a problem. If this new child is moved/copied here, then we'll end up with that information in copyfrom_*, and can distinguish the ancestor's move/copy from this child's move/copy. But if you simply "add", then we have no way to determine that this add is NOT the child implied by the ancestor's move/copy to this location. There is no defined marker. Grr. Maybe we have a qualified value for copyfrom_repos_id that means "locally-added" ? We could set this on the root of all local-adds. Thoughts? (and thanks for finding this hole!!) Cheers, -g
