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 <philip.martin_at_wandisco.com> wrote:
> "Bert Huijben" <bert_at_qqmail.nl> 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
> 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.
> 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.
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.
(and thanks for finding this hole!!)
Received on 2010-02-17 20:02:12 CET