[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-14 21:56:36 CEST

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
Received on Tue May 14 21:59:56 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.