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

questions for cmike

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-06-27 00:45:53 CEST

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

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

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