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

Use new "entity ID" notion instead of "committed rev"



    • New Feature
    • Status: Open
    • Critical
    • Resolution: Unresolved
    • all
    • 2.0-consider
    • None
    • None


      The concept of the committed revision on a given path turns out to be not so
      useful.  Examining two different paths and their CRs, you can't tell if the
      paths reflect the same line of history, you can't assume that changes in the
      path with the higher revision number are also included in the other path.  Even
      if the two paths *do* reflect the same line of history, you have no idea how
      much churn has occured between the two revisions (there could be any number from
      0 to N-M commits  to a path between revisions M and N).  And people seem to
      really want, on a per path basis, a monitonically increasing count of committed
      changes to that path.
      And this isn't even touching the wealth of issues that occur when trying to
      maintain a committed rev in light of our "cheap-copy" FS model.  *Shudder*.
      No, CR ain't the way to go.
      But in a relatively recent brainstorming session of myself, jackr, sussman, and
      kfogel, I stumbled across this idea of an "entity ID" (though that might not
      have been what we called it -- could have been "resource version string" or
      something).  Anyway, this thing consists of the tuple (NodeId, BranchId,
      ChangeCount), where:
       - (NodeId) uniquely identifies a line of history,
       - (NodeId, BranchId) unique identifies a particular branch of a line
       - (NodeId, BranchId, ChangeCount) uniquely identifies a particular
          version along a particular branch of a line of history, and
       - ChangeCount increases monotonically with each commit to that line
          of history.
      We think we can generate this thing using the filesystem's NodeId, CopyId, and
      (get this) the PredecessorCount (from the skip-delta code!).  The idea would be
      to replace the client-side CR with this puppy, including an expandable
      svn:keyword for it, so that you could, say, look at two printouts of various
      versions of a document that are lying on a table and, presuming you know they
      are from the same repository (perhaps we should toss the UUID into the tuple? 
      Hm...), say with confidence, "These are two versions of the same document, along
      the same line of history, *this* one is the youngest one, and there were X
      revision between the two versions."


        Issue Links



              Unassigned Unassigned
              cmpilato C. Michael Pilato
              0 Vote for this issue
              1 Start watching this issue