In 1.6 svn_wc_entry_t had a 'copied' field that was used to distinguish
copies from adds. In 1.7 we have compatibility code that constructs
1.6-like entries from the 1.7 metadata, so it has to set the copied
flag. In 1.6 this flag gets set on all the entries in a copied tree, so
1.7 does the same. However if nodes in the copied tree are deleted 1.7
clears the copied flag for those nodes. There are comments scattered
about:
entries_tests.py:237
# case (1) of the DELETED nodes COPIED handling (see comment in
# read_entries). we are a deletion of a copied subtree. thus, extra
# work at commit time. thus, not COPIED.
# oh, and this sucker has a URL, too
entries.c:340
Not so fast. Back to the general concept of "an ancestor
operation took care of me." Further consider two possibilities:
1) this node is scheduled for deletion from the copied subtree,
so at commit time, we copy then delete
2) this node is scheduled for deletion because a subtree was
deleted and then a copied subtree was added (causing a
replacement). at commit time, we delete a subtree, and then
copy a subtree. we do not need to specifically touch this
node -- all operations occur on ancestors.
Given the "ancestor operation" concept, then in case (1) we
must *clear* the COPIED flag since we'll have more work to do.
In case (2), we *set* the COPIED flag to indicate that no
real work is going to happen on this node.
The problem I have is that 1.6 does not behave this way. In 1.6 the
copied flag is set on deletes within a copy. I don't understand why 1.7
is doing it differently. My guess is that at some point in the past the
copied flag was used internally by the WCNG code. However these days
the compatibility code is just a read-only view of the metadata for
clients that want to use the 1.6 interface, setting/clearing it has no
effect on 1.7 operations.
Can anyone recall why 1.7 is different?
--
Philip
Received on 2010-12-08 11:55:19 CET