svn commit: r966804 - /subversion/branches/issue-2779-dev/BRANCH-README

[cm...@apache.org]

Author: cmpilato
Date: Thu Jul 22 19:00:43 2010
New Revision: 966804

URL: http://svn.apache.org/viewvc?rev=966804&view=rev
Log:
On the 'issue-2779-dev' branch:

* BRANCH-README
  Update the plan and status.

Modified:
    subversion/branches/issue-2779-dev/BRANCH-README

Modified: subversion/branches/issue-2779-dev/BRANCH-README
URL: http://svn.apache.org/viewvc/subversion/branches/issue-2779-dev/BRANCH-README?rev=966804&r1=966803&r2=966804&view=diff
==============================================================================
--- subversion/branches/issue-2779-dev/BRANCH-README (original)
+++ subversion/branches/issue-2779-dev/BRANCH-README Thu Jul 22 19:00:43 2010
@@ -3,37 +3,54 @@ This branch is for development towards a
 maintained as a reintegrateable branch, with occasional syncs from
 ^/subversion/trunk.
 
+
+APPROACH
+========
+
 The solution's approach is as follows:
 
   1. Teach the RA DAV providers to recognize 301 and 302 responses to
      the initial OPTIONS request they always perform as part of
      session opening and capabilities exchange.
 
-      - ra_neon [DONE]
-      - ra_serf [see issue #3685]
+       - ra_neon  [DONE]
+       - ra_serf  [see issue #3685[2]]
 
   2. Rev svn_ra_open3(), teaching the new version to gracefully return
-     the suggested URL provided by the server, while still allowing
+     the corrected URL provided by the server, while still allowing
      old versions to error out on redirections/relocations as they do
      today.  [DONE]
 
-  3. Teach the client 'checkout', 'update', and 'switch' commands to
-     recognize these relocation responses and retry the operation
-     after performing relocation of the working copy (if necessary).
+  3. Teach some subcommands to deal with corrected URLs from the 
+     RA layer, relocating their targets as necessary.
+
+       - checkout  [DONE]
+       - update  [DONE]
+       - switch
+
+Then, either:
 
   4. Provide notification of redirection events to the user.
 
-  5. Make the retry-on-new-URL event an optional behavior, tied to the
-     particular server and defaulting to 'off', recognizing that
-     there's a security element here (compromised server, redirecting
-     folks to dangerous code, etc.)
+  5. Make the retry-on-corrected-URL event an optional behavior, tied
+     to the particular server and defaulting to 'off', recognizing
+     that there's a security element here (compromised server,
+     redirecting folks to dangerous code, etc.)
 
+or:
 
-Questions:
+  4. Bind the retry-on-corrected-URL event to a prompting callback.
+
+
+QUESTIONS
+=========
 
   - Should only permanent relocations (301 Moved Permanently) be
-    handled specially?
+    handled in this way?
 
   - Do we want run-time configuration for auto-relocation?
 
-[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2779
\ No newline at end of file
+
+------------------------------------------------------------------------------
+[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2779
+[2] http://subversion.tigris.org/issues/show_bug.cgi?id=2685
\ No newline at end of file