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