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

issues on the table

From: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2001-01-03 18:56:32 CET

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(). In both cases, 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.


      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.

* RA-Dav Issues

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


      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.


      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.
Received on Sat Oct 21 14:36:19 2006

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.