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

Re: "not under version control" error - continued

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-02-11 21:07:29 CET

On Tue, 2004-02-10 at 19:08, Philip Martin wrote:

> It's still a bug. The dry-run merge doesn't handle properties on
> added files. Is there an issue in the issue tracker? If not, you
> should raise one.

I filed this bug as issue 1738 and committed an XFail regression test.

In gdb, the immediate problem is obvious: repos_diff.c calls the
props_changed callback, which is diff.c:merge_props_changed(), which
then calls svn_wc_merge_prop_diffs(). That last function tries to grab
an entry for (A)dded file, which doesn't exist, and throws the error.

I think the key to solving this problem is just not to invoke the
props_changed callback at all... that is, don't ever invoke it on a file
that is schedule-add when 'dry run' is active.

I think the code at repos_diff.c:811 is *trying* to avoid this
situation, but I don't quite understand the comment:

  /* Don't do the props_changed stuff if this is a dry_run and we don't
     have an access baton, since in that case the file will already have
     been recognised as added, in which case they cannot conflict. A
     similar argument applies to directories in close_directory. */
  if (b->propchanges->nelts > 0 && (! eb->dry_run || adm_access))
      SVN_ERR (eb->diff_callbacks->props_changed
               (adm_access, &prop_state,
                b->propchanges, b->pristine_props,

I made a tiny patch to this condition:

- if (b->propchanges->nelts > 0 && (! eb->dry_run || adm_access))
+ if (b->propchanges->nelts > 0 && (! eb->dry_run) && adm_access)

...and it fixes the problem, but causes merge_test #4 to fail. What's
the correct logic here? Philip? Anyone?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 11 21:12:07 2004

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

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