Chia-liang Kao <firstname.lastname@example.org> writes:
> According to svn_delta.h:
> * 4. A producer must call @c change_dir_prop on a directory either
> * before opening any of the directory's subdirs or after closing
> * them, but not in the middle.
> but in commit.c: (change_dir_prop):
> SVN_ERR (svn_fs_node_created_rev (&created_rev,
> eb->txn_root, db->path, pool));
> if (db->base_rev < created_rev)
> return out_of_date (db->path, eb->txn_name);
> If the directory is modified in this transaction, such as a file
> within it is modified, the node_created_rev check here would find the
> directory up-to-date and hence allow the change_dir_prop which should
> cause out_of_date.
After chatting with Mike Pilato about this, I think there is a
confusion of two independent questions here (plus the documentation
could be clearer).
The rule in svn_delta.h is not about out-of-dateness. It's about the
order of editor calls -- it's trying to give callers some guidance
about what order to do things in. I'm not actually sure why it
specifies this particular order, but in any case it's not about
out-of-dateness. For example, note that the rule does not talk about
files which have changed in the target directory, even though those
would make a difference in out-of-dateness as much as subdirs would.
Regarding the code, I think the comment there (not quoted above) could
be updated to say that the directory may be modified in this txn, but
then must at least be "based" on an up-to-date directory.
Before I tweak that comment, though, I'd like your confirmation that
what I'm saying makes sense.
> I wonder if there is any use of change_dir_prop before close_directory
> (besides svk)?
Mike actually has an ambition to change the ordering requirements (and
therefore our implementations) to make all property changes to a given
target happen *before* any content changes. This might help us solve
issue #2064 too. However, this ambition is only semi-related to your
original question, I think.
I don't know whether any part of Subversion is violating its own
ordering guidelines. (Are you saying svk is?)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 3 22:11:19 2004