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

redefine revprop handling in FSFS f5 (creating FSFS f6)

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: 1.8.0
    • Component/s: libsvn_fs_fs
    • Labels:
      None

      Description

      http://mid.gmane.org/OFF5DC1071.793EFD7C-ON862578BF.005304DA-
      862578BF.00552DB1@rockwellcollins.com
      
      Kevin started the thread, saying that the choice to store revprops in non-cp(1)-safe storage (SQLite) 
      was to him a major regression.
      
      Several suggestions flew by, including:
      
      1. Make it possible to pack revisions without packing revprops.
      
      2. Do away with revprops/ shards, instead have ALL properties in the SQLite db.
      
      3. Keep revprops in the DB, when they're edited store them back to plain files which 'pack' would 
      then move back to the DB.
      
      I'll add my opinion shortly.
      
      In any case, changes to f5 must be made before that format is released, so I'm marking this as a 
      release blocker.
      

        Issue Links

          Activity

          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          Assign to self.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - Assign to self.
          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          I'm +1 on the second suggestion and -0 on the third (in both cases due to simplicity-v-complexity 
          scale).  I'm also +0.5 on the first suggestion.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - I'm +1 on the second suggestion and -0 on the third (in both cases due to simplicity-v-complexity scale). I'm also +0.5 on the first suggestion.
          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          I'm moving this to 1.8, since the design discussions don't seem to keep springing new ideas and no 
          one wants to redesign the FS under time pressure and release it a week later.
          
          In the meantime the thread has grown with several suggestions (some of which should be 
          implemented), and design and implementation have started on the revprop-packing branch.
          
          In the meantime, I'll open a new issue to rip out FSFS f5 from trunk.  (The new code will be called f6.)  
          That's all we need to do prior to 1.7.0.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - I'm moving this to 1.8, since the design discussions don't seem to keep springing new ideas and no one wants to redesign the FS under time pressure and release it a week later. In the meantime the thread has grown with several suggestions (some of which should be implemented), and design and implementation have started on the revprop-packing branch. In the meantime, I'll open a new issue to rip out FSFS f5 from trunk. (The new code will be called f6.) That's all we need to do prior to 1.7.0.
          Hide
          subversion-importer Subversion Importer added a comment -

          I still prefer the design of packing just as with rev data, and then unpacking on-
          demand if an old revprop is edited. We then re-pack the next time svanadmin pack 
          is run. The data is small, and the impact is minimal.
          

          Original comment by rmalayter

          Show
          subversion-importer Subversion Importer added a comment - I still prefer the design of packing just as with rev data, and then unpacking on- demand if an old revprop is edited. We then re-pack the next time svanadmin pack is run. The data is small, and the impact is minimal. Original comment by rmalayter
          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          Design proposals to dev@ please, not here.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - Design proposals to dev@ please, not here.
          Hide
          stefan2 Stefan Fuhrmann added a comment -

          Implemented as of r1358726 for 1.8.
          
          Note that the code is not copy-safe. Backup software as mentioned in the
          original report must use proper snapshots. This has already been true for
          ordinary revision data packing.
          

          Show
          stefan2 Stefan Fuhrmann added a comment - Implemented as of r1358726 for 1.8. Note that the code is not copy-safe. Backup software as mentioned in the original report must use proper snapshots. This has already been true for ordinary revision data packing.

            People

            • Assignee:
              Unassigned
              Reporter:
              danielsh Daniel Shahaf (äñ§€¥£¢)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development