So now I'm looking at issue #742, and I'm hoping cmpilato (or others)
can enlighten me on some things.
The bug: if you try to commit a file that's scheduled for replacement,
and the original file had props... then you get a failure.
Here's what's happening under the hood:
1. assume 'iota' has some properties.
2. svn rm iota
iota is now scheduled for deletion.
3. touch iota
4. svn add iota
the function svn_wc_add() has special code (adm_ops.c:799) that
detects that the add is actually a replacement, and *deletes*
the local prop file if present. This makes sense: a newly
added file shouldn't start life with properties, after all.
(Also, this means 'svn revert iota' can still remove all
scheduling and restore the original props from .svn/prop-base/)
5. svn commit
Now we run into trouble. harvest_committables() notices
schedule=replace on the entry, and sets both DELETE and ADD
bitflags on the 'state_flags' variable.
Then because of the ADD flag, this function calls
svn_wc_props_modified_p, and decides, "yes, there are prop mods to
send." This is the main problem. In a replacement, we shouldn't
be comparing local-props against base-props at all. Maybe
svn_wc_props_modified_p should notice (schedule=replace ||
schedule=add) on the entry, and just check for the existence of the
localprops. IFF it exists at all, then file has prop mods. (?)
Anyway, because of this false positive, do_item_commit() eventually
ends up calling svn_wc_transmit_prop_deltas() when it shouldn't.
The latter function chokes when it tries to copy a nonexistent
local-propfile to .svn/tmp/. But even *this* is problematic. If I
had added some props to the new iota before committing, then this
function would be sending propchanges against the old prop-base,
rather than sending propchanges against an empty hash, as it
should!
So in summary, I suspect we need two things:
1. make svn_wc_props_modified_p() smarter, as described above
2. svn_wc_transmit_prop_deltas() needs to be smarter too, in the
same way.
In other words, both of these functions need to notice a schedule add
or replacement, and know to *ignore* the base-props.
cmpilato, does this sound reasonable? I ask you because you
essentially rewrote all of this code in adm_crawler.c, and you're more
familiar with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 26 23:50:13 2002