Re: svn commit: rev 1953 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client trunk/subversion/clients/cmdline

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

sussman@tigris.org writes:

> Author: sussman
> Date: 2002-05-14 19:36 GMT
> New Revision: 1953
> 
> Part I of issue #658: reinstate the 'deleted' flag on entries, so that
> updating clients can once again give accurate state-reports to the
> server.

Here's an explanation of what I'm doing, for people who weren't
around a year ago.  I figured it might be educational to make my
private notes into public ones:


* When does an entry get the 'deleted' flag attached?

    When we commit a deletion.  In other words, in the post-commit
    processing phase, we notice if the committed item was deleted in
    the commit.  If the item has a different 'new' revnum than
    parent's revnum, mark entry 'deleted'.

* Who uses the 'deleted' flag?

    The state-reporter.  When it crawls the working copy, it will
    report a deleted entry as 'missing' to the reporter vtable.

* When does the 'deleted' entry go away?

  1. In the post-update processor.  If the deleted entry hasn't been
     completely overwritten during the update by a new item of the
     same name, then the server obviously intended the item to stay
     deleted.  So the entire entry is removed.

  2. In the post-commit processor.  If the deleted entry has the -same-
     revnum as its parent, then the parent must have been committed as
     well, and thus it's safe to remove the child entry completely.

* How to implement this cleanly?

   Add a flag to svn_wc_entries_read and svn_wc_entry, indicating
   whether a deleted entries should be returned.

   Generally, anyone who gets a single entry or a list of entries will
   NOT want deleted entries returned. 

   Only the routines listed above will want to see them:

        - post-commit processor
        - post-update processor
        - state-reporter

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