Re: [PATCH] Explain svn_wc_entry_t's "deleted" flag.

Julian Foad wrote:
> * subversion/include/svn_wc.h
> (svn_wc_entry_t): Explain the "deleted" flag a bit better.
>
> [[[
> Index: subversion/include/svn_wc.h
> ===================================================================
> --- subversion/include/svn_wc.h (revision 34116)
> +++ subversion/include/svn_wc.h (working copy)
> @@ -1894,7 +1894,9 @@
> when the entry itself is @c svn_wc_schedule_normal) */
> svn_boolean_t copied;
>
> - /** deleted, but parent rev lags behind */
> + /** deleted, but parent rev lags behind. Only applicable to a 'this_dir'
> + * entry. An entry can be 'deleted' and also schedule-add, meaning this
> + * entry is for a new directory that will replace the old one. */
> svn_boolean_t deleted;
>
> /** absent -- we know an entry of this name exists, but that's all
> ]]]
>
> Is this right?

I ... don't think so. deleted != "scheduled for deletion". I'm not sure
how to best describe it. Maybe a scenario will help (sorry if the below
isn't verbatim ... I'm winging it):

  $ svn update dir
  Updated to revision 4.
  $ svn rm dir/some-file
  $ svn ci -m "delete some-file"
  Deleting dir/some-file
  Committed revision 5.
  $

At this point, we have 'dir' at revision 4, and 'dir/some-file' is gone.
But we need the entries file for 'dir' to list all of dir's children *as of
revision 4*. So we leave 'some-dir' in that entries list, but mark it with
this special 'deleted' flag so we know that the record is there only to
ensure the integrity of the entries list for 'dir'.

Back in the day, we referred to the problems caused by *not* storing these
special "deleted" records as "ghudson bugs" (after their reporter, not their
composer).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand