[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: repos_commit_editor and change_dir_prop

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-11-04 06:51:49 CET

Chia-liang Kao <clkao@clkao.org> writes:

> Yes, I understand this fully. The ordering rule #4 allows
> change_dir_prop to be called right after open_directory or before
> close_directory. However, the logic I pointed out in out-of-dateness
> check is invalid in the latter case. Consider an out-of-date
> directory 'foo' where it fails to:
> open_directory ('foo');
> change_dir_prop ('foo', 'prop', 'value'); # out-of-date
> But the following order will not error out:
> open_directory ('foo');
> open_file ('foo/bar');
> apply_textdelta ('foo/bar', ...);
> close_file ('foo/bar');
> change_dir_prop ('foo', 'prop', 'value');
> with the file change at 'foo/bar', the node_created_revision of 'foo'
> in the txn is updated and is definitely up-to-date at the last
> change_dir_prop, which is wrong and allowing out-of-date editor call
> to go through commit.

You are correct, and I apologize on behalf of my mother, who called my
desk phone today while Karl and I were talking about this, just as I
was starting to understand the bug you were pointing out, and
initiating a conversation that extended past the time at while Karl
sent his response to you.

And the answer to one of your original questions appears to be that
yes, existing callers of that API happen to (luckily) use the former
ordering (which correctly detects out-of-dateness). And I suppose
that svk happens *not* to use that ordering, else you likely wouldn't
have been motivated to inquire about the situation.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 4 06:54:24 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.