My head spins, but probably not so much as Jimb's will when he
returns. :)

Here's a summary of my understanding of the status quo.


* Editor Changes

  * Description: replace_file() and replace_dir() no longer 
                 need ancestry paths.

    Status:      RESOLVED.

      We've agreed that replace_file() is only to be used for applying
      text or prop deltas.  If we're replacing the file with a
      completely new dirent, we treat is as a *directory* change by
      doing a delete() and add().  For both files and directories, the
      ancestor path of a replace_*() call is inferred from the parent
      directory baton.  Revision numbers are still needed, however.

  * Description: allow multiple replace_root() calls within an edit.

    Status:      STILL DISCUSSING.

      Most of us like this change; it has no theological problems.
      We'd like to get jimb's feedback before we start implementing
      it, as it involves a lot of re-coding.  (e.g. replace_root()
      would now need to take a path argument!)  However, it will make
      the problem of "multiple targets on the command line" much
      easier to deal with.

   kff notes: actually, Greg Hudson is iffy about this and, on
   reflection, so am I.


* RA-Dav Issues

  * Description:  The network layer needs to get/set props in the WC
                  while driving the WC's update-editor.

    Status:       STILL DISCUSSING.

      We understand that two "private cookie" bits need to be stored
      as WC properties: one activity URL, and one versioned resource
      URL.  It's easy to set props while updating the working copy --
      the editor interface already allows that.  But how about
      querying props?  Unless we add this ability to the editor
      interface, the RA layer is going to somehow have to figure out
      *actual* WC disk paths to use svn_wc_prop_get()... major icko.

      However, ra_dav probably won't be the only network layer to need
      this feature, so we still need to come up with a good solution.

      (This issue might be filed under "editor changes" above.)

  
  * Description:  Need to decide how revision numbers are requested
                  within the svn_ra_plugin_t vtable.

    Status:       STILL DISCUSSING.

      How do we check out a particular revision of a tree, or update
      to a particular version of resource?  We need to hash out these
      details in the arguments to RA functions.  Karl and Greg never
      resolved this, I believe.  


* WC Issues

  * Description:  Implementation issue:  how do we store the {repos,
                  repos_path, revision} tuple in the `entries' file?
                  How are they composed/dissected to/from URL-ness?

    Status:       RESOLVED.

      An entry item within the `entries' file will store two fields:
      one attribute will be named "public-url" and contain a
      concatenation of the repository URL and repos_path.  The other
      attribute will be named "revision" and hold the revision.  This
      is the only "public" viewable instance of a revision.

      During an update, the WC library will bump this public revision
      number.  However, the RA will also store the private
      versioned-resource URL as a property.  People seem to be in
      agreement that we *don't* need to ensure that the public and
      private revisions stay in sync.


* FS Copy Model

  * Description:  When a "copy" is made in the repository, the plan
		  has been to simply link the source's node into the
		  target directory. However, this does not keep enough
		  information about the change and the history for the
		  "new" node.

		  [ specifically: we cannot tell if a given node is a
		    copy of something else, and where it may have come
		    from. ]

    Message-Id:   <20010102204643.L17220@lyra.org>
		  ... and the resulting, short, thread.

    Status:	  STILL DISCUSSING
		  (pending comments from JimB)