I've checked this in as subversion/notes/issues.txt. If anyone has
comments or additions, please use that file.
-K
Ben Collins-Sussman <sussman@newton.collab.net> writes:
> 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.
>
> 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.
>
>
>
> * 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.
>
>
Received on Sat Oct 21 14:36:19 2006