Re: Nifty switch/update bug

On Wed, 2004-05-12 at 17:35, kfogel@collab.net wrote:
> Yick.
>
> No idea offhand what's causing this. Would you like me to file, though?

Sure, please go ahead.

After the switch operation, libsvn_fs_base/bdb gets left behind with no
.svn directory, but there is still a corresponding skeletal entry in
libsvn_fs_base/.svn/entries:

<entry
   name="bdb"
   kind="dir"/>

During the locking phase, lock.c:do_open() finds the bdb subdir,
recurses into it, but then notices that there is no .svn/format file and
errors out. The error is caught and a "missing" entry is stored in the
adm_access set. During the crawl phase, report_revisions() attempts to
retrieve libsvn_fs_base/bdb and dies because "missing" entries are
treated as NULL and result in an error.

If libsvn_fs_base/bdb is deleted completely, then report_revisions()
does the right thing; it notices that the directory is missing (using
the local boolean variable "missing", which is based on the dirents of
libsvn_fs_base) and skips trying to retrieve it.

So, we have one or two problems:

  1. Perhaps svn switch should not be leaving behind the skeletal
entries for libsvn_fs_base/bdb.

  2. Operations which crawl the working copy (update, diff, switch,
status -u) fail in the presence of version-controlled subdirs with no
.svn subdir.

An easier recipe for #2 is:

  <check out the svn trunk and cd into it>
  rm -rf notes/.svn
  svn up

Of course, that recipe looks less like a bug than the "svn switch"
recipe because of the rm -rf step.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 13 03:14:49 2004