| 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) |