another ghudson-'deleted'-type bug?

[Ben Collins-Sussman <su...@collab.net>]

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

Re: another ghudson-'deleted'-type bug?

[Karl Fogel <kf...@newton.ch.collab.net>]

cmpilato@collab.net writes:
> The latter is what I have always assumed was the definition of the
> deleted flag.  It exists as a placeholder of the existence of a thing
> in the revision that parent direcotory claims to have, irrespective of
> their relative "ages".

Agreed, that's what I always assumed it meant too.

Filed issue 919 for this.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: another ghudson-'deleted'-type bug?

[cm...@collab.net]

Ben Collins-Sussman <su...@collab.net> writes:

> 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."

[...]

> 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."

The latter is what I have always assumed was the definition of the
deleted flag.  It exists as a placeholder of the existence of a thing
in the revision that parent direcotory claims to have, irrespective of
their relative "ages".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org