commit mechanism

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

OK, so I did a lot of coding this weekend, only to find out that I'm
right in the miile of a design dispute about exactly how
svn_client_commit() should work.  My code is halfway between. :)

Rather than check in my work, let me present the two sides here.


Scenario 1 (Karl's Way):

  * Let svn_client_commit *always* bump revisions after driving the
    commit editor, using the target list returned from
    crawl_local_mods.

  * Modify ra->get_commit_editor prototype so that 

       * ra layer no longer bumps individual targets after a commit 
       * we can somehow get the new revision number back into
         svn_client_commit.

  * The track editor goes away completely, it's no longer needed.

  * Committing to XML is no longer a special case;  it's just another
    editor to fetch instead of an RA one.

  -- This design is based on the idea that "svn_client_commit"
     embodies the fulfillment of a complete commit.  In this scenario,
     the commit editor is just a communication tool to write changes
     into a repository.

Scenario 2 (Greg's Way):

  * Put the track editor in libsvn_ra, and modify it to do *nothing*
    but build a target list at a particular address.

  * ra_local uses the track editor under the hood.

  * svn_client_commit treats XML as a special case:

       * compose it with the track editor before driving the commit.
       * after the commit, loop over track editor's list and bump
       * targets.

  -- This design is based on the idea that "driving a commit editor"
     embodies the fulfillment of a complete commit.  In this scenario,
     the commit editor actually completes the commit, not its caller.