Hi all,
I have a patch that passes 'make check', but changes the behaviour of
svn_client__get_revision_number() in ways that surpass my current
understanding. Previously, this function would follow the
overloadedness of entry->revision, in ways not entirely clear to me.
read_entries_new() does these things WRT entry->revision:
- get the revision from __read_info()
- if status_added, pick up the parent node's revision instead
- but if base_shadowed, use the NG-BASE node's revision.
- if not_present, use NG-BASE node's revision
- if plain add, set revision = 0
- if obstructed_add, set revision = SVN_INVALID_REVNUM
- if copied, set revision to scan_addition's ORIGINAL_REVISION
When svn_client__get_revision_number() was called with
svn_opt_revision_base or svn_opt_revision_working, it just returned
the entry->revision. Frankly, it's a bloody nightmare to figure out
what happened when, exactly.
Instead, I intend to implement svn_client__get_revision_number() with
svn_opt_revision_base | svn_opt_revision_working like this:
return the commit-base (not the revert-base) revision. i.e., return
the NG-BASE node's revision, but:
if the node is copied here, return the copy_from revision;
if the node is plainly added, even if the node is replaced by a
plain add, return SVN_INVALID_REVNUM.
Attached patch implements that AFAICT, but I note some behaviour
changes (I did a dumb printf() of every revision returned and compared
trunk's make check output to my patch)
- Added nodes now return revision number -1 instead of 0 (expected)
- Copied-here nodes seem to have sometimes returned an earlier
revision than the copy_from revision that this patch returns
(unexpected to me)
Note once more that the patch passes 'make check'. But I am unsure
whether I really understand what I'm doing. Comments welcome.
Less importantly, another change is in the returned error message. If
the function was called on a node not under version control, it would
issue an SVN_ERR_WC_PATH_NOT_FOUND with error string "'foo' is not
under version control". With this patch, svn still returns the same
error code, but an error message of "'foo' was not found." (see the
change of diff_tests.py in attached patch) -- I'm wondering if I
should mangle the error message to be identical to previous behaviour.
The old message makes slightly more sense to humans in this case,
right?
Thanks,
~Neels
Received on 2010-03-31 12:53:33 CEST