another ghudson-'deleted'-type bug?

I was sitting in my libsvn_repos/ working copy, and ran

  $ svn up -r1 repos.c
  D repos.c

Indeed, it didn't exist back then. Oh well, let me get it back. I
shrugged and ran

  $ svn up repos.c
  subversion/libsvn_wc/update_editor.c:2146: (apr_err=150000, src_err=0)
  svn: Can't find an entry
  svn: svn_wc_is_wc_root: repos.c is not a versioned resource

There was no 'deleted' entry. repos.c was completely gone from the
entries file.

Running 'svn up' on the parent didn't help either -- it just happily
reports being at r3329... it has no idea it's missing anything. (This
relates to the whole can't-resume-checkouts bug.)

My solution was to 'svn up -r1' the whole parent dir (which involved a
no-op delete of repos.c), and then 'svn up' the whole parent dir
again.

Anyway -- is this a bug? It sure is confusing.

Up till now, we've always created entries with the 'deleted' flag as a
way of saying, "this entry exists in the parent's rev, but is deleted
in a *later* revision... which happens to be the rev of this file."

This always happens after committing a deletion. When the parent
updates to any specific revision, it reports the deleted-entry as
missing, and then the server either overwrites the entry, or if not,
we just remove the entry after the update is finished.

But now we have a case where perhaps we should have a 'deleted' entry
at a much earlier revision than its parent. Is this a scenario we've
overlooked? Perhaps the 'deleted' flag should have a more general
meaning, like "this entry exists in the parent's rev, but is deleted
in *this* revision that the file happens to be at."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 8 17:16:23 2002