Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2161

Finish autoversioning feature.

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.x
    • Fix Version/s: 1.2.0
    • Component/s: mod_dav_svn
    • Labels:
      None

      Description

      The mod_dav_svn autoversioning feature, documented in appendix C of the book, has always been 
      half-implemented, mainly because of the lack of support for http LOCK and UNLOCK methods.  Users 
      could drag files into a mounted svn DAV share, but they couldn't open files directly "from" the share.
      
      Now that svn 1.2 has real locking support, autoversioning is 95% complete.  LOCK and UNLOCK 
      methods work correctly.  There seems to be only 1 buglet left.  This buglet has always existed in the 
      autoversioning code, but it wasn't until we added the new locking code that it started manifesting itself:
      
      When changing an existing file, we get one autoversioning commit, as expected.  But when adding or 
      deleting a file, we end up with two commits;  one for the add or delete, and one "no-op" commit on the 
      parent directory!
      
      This is happening due to DeltaV semantics.  When editing an existing file, mod_dav does an "auto-
      checkout" of the file before the edit, and an "auto-checkin" afterwards.  But when adding or deleting an 
      item, mod_dav does an auto-checkout/auto-checkin of the *parent* directory.
      
      The current implementation of autoversioning is being sloppy about fs txns.  Whenever anything is 
      auto-checked-out, we create a new fs txn.  And whenever anything is auto-checked-in, we commit the 
      fs txn.
      
      So to see what's happening, here's what happens during an autoversioning 'DELETE foo.c' request:
      
       1. mod_dav auto-checks out the parent dir --> dav_svn_checkout() creates fs txn 1
       2. mod_dav deletes the child --> dav_svn_remove_resource() creates fs txn2 AND commits it.
       3. mod_dav auto-checks in the parent dir --> dav_svn_checkin() commits fs txn 1
      
      But no changes ever happened to fs txn 1;  it's a commit with no changed paths.
      
      One weasely solution is to prevent dav_svn_checkin() from committing a no-op fs txn.  Let's not do 
      that.
      
      The better solution (after talking with kfogel and gstein) is to really map DeltaV semantics to svn 
      semantics:  the deletion (or addition) should be happening in the *parent's* fs txn, not in a separate 
      txn.  Unfortunately, the parent resource isn't usually available to most of the dav_svn_* functions.  So 
      what we need to do is have dav_svn_checkout() create a 'global' fs txn attached to the apache request 
      record ("r"), and make every autoversioning command use that txn.  Then dav_svn_checkin() will 
      commit r->info->txn.
      
      This will require a couple of days of work... just some basic autoversioning code re-org in 
      mod_dav_svn, nothing scary.  And the net effect is that it will stop these extra no-op commits from 
      happening, and then we can officially pronounces autoversioning a "done" feature.
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              sussman Ben Collins-Sussman
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: