M-x big-picture

Alpha Checklist (?)

The client-side of things is much further along than the server-side
of things. Before we start focusing all of our attention on the
filesystem, I wanted a clean list to (later) remind us how to jump
back into the rest of the project. STACK has turned into a big mess
-- and that's okay, it's a scratch area. This is something cleaner
for future reference.

Assuming the filesystem is up and running, I believe this is a list of
everything that needs doing before we can start to admit that we're
getting close to a QA'able first "alpha" release of subversion.

 * write general "multiple target" logic in client

    * need shared code which will

       * remove redundant targets from a target list
       * find the longest common ancestor path of a target list

    * need to make all libsvn_client commands utilize this logic

    * updates need to bump revisions on everything, not just changed
      objects.

 * general changes #2, 3, 4, 5, 6, 7

   Change #2: Modify prototypes of replace_*() and add_*()
   Change #3: New "WC" properties.
   Change #4: Revise the commit cleanup process. (in svn_ra.h)
   Change #5: The "report" editor doesn't exist.
   Change #6: Move textdeltas to the "other side" of the editor.
   Change #7: New filesystem "copy" nodes implies renaming add_*() args

 * ra_dav -- this is GREG'S BIG PROJECT. :)

 * ra_local:

      * --> editor interface which writes to a fs transaction
      * <-- routines to read the fs and drive update editor

 * make sure the client can handle moves/renames/copies:

      * <-- update editor should gracefully handle "adds with
        history" (the essence of moves/rename/copy).
      * --> `svn mv/cp' should register a `delete' and
        `add-with-history' in the WC entries files.

 * branching and merging commands

 * log history commands

 * annotate commands

 * cvs --> svn repository converter

--------------------

Things that should *probably* be in SVN 1.0, but not necessarily:

 * tracking of changeset-like metadata, so we can do "genetic merging"

 * client-side diff plugins (in command-line client)

 * win32 gui

 * svn --> cvs (lossy) repository converter

--------------------

Remember that for SVN 1.0, we need *compelling* reasons to make
somebody switch to it over CVS. Right now, assuming SVN does
everything CVS does, those compelling reasons are:

   * much, much faster networking

   * versioning of directories, moves, renames.

These are probably the two largest gripes of CVS users.
Received on Sat Oct 21 14:36:20 2006