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

FS API support for oldest-to-youngest history traversal

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: trunk
    • Fix Version/s: 1.10-consider
    • Component/s: libsvn_fs
    • Labels:
      None

      Description

      Also known as "forward history searching", this enhancement brings to the
      libsvn_fs API the ability to traverse the chain of "interesting history points"
      for a line of versioned history in an oldest-to-youngest fashion.  Today's API
      allows only the opposite:  starting with a path/revision pair, walk backwards
      through the past changes in that line of history.  This functionality flows
      naturally out of the current FS design, which stores for each node-revision a
      reference to that node-revision's predecessor node-revision.  Currently there is
      no FS-level storage of the reverse-link -- the successor node-revisions.  And
      yes, there's a 1-to-many relationship of node-revisions to their successors
      because successors are created both by modifications to a versioned item and by
      copying those items elsewhere (which can happen any number of times).
      

        Activity

        Hide
        cmpilato C. Michael Pilato added a comment -

        This API support is critical to a number of high-level user needs:
        
          - answering the question, "To how many places has version X of file FOO (which
        is known to have some nasty bug in it) been copied?"  (So those copies can be
        fixed, too.)
        
          - rendering repository history graphs quickly.
        
          - allowing 'svn log' to fully traverse the entire history of a given versioned
        object, both for completeness' sake and to facilitate (for example) resurrection
        of deleted items from their most-recently-existing forms.
        

        Show
        cmpilato C. Michael Pilato added a comment - This API support is critical to a number of high-level user needs: - answering the question, "To how many places has version X of file FOO (which is known to have some nasty bug in it) been copied?" (So those copies can be fixed, too.) - rendering repository history graphs quickly. - allowing 'svn log' to fully traverse the entire history of a given versioned object, both for completeness' sake and to facilitate (for example) resurrection of deleted items from their most-recently-existing forms.
        Hide
        cmpilato C. Michael Pilato added a comment -

        Some work has been done for the BDB backend for this issue, and lives on the
        'fs-successor-ids' branch.  Nothing has been attempted for FSFS at this point.
        

        Show
        cmpilato C. Michael Pilato added a comment - Some work has been done for the BDB backend for this issue, and lives on the 'fs-successor-ids' branch. Nothing has been attempted for FSFS at this point.
        Hide
        cmpilato C. Michael Pilato added a comment -

        Other benefits (as noted by stsp):
        
          - better rename tracking ('copyto' info for deleted items)
        
          - improved tree conflict detection/resolution (due to the above)
        

        Show
        cmpilato C. Michael Pilato added a comment - Other benefits (as noted by stsp): - better rename tracking ('copyto' info for deleted items) - improved tree conflict detection/resolution (due to the above)
        Hide
        jcorvel Johan Corveleyn added a comment -

        Re:
        [[[
          - answering the question, "To how many places has version X of file FOO (which
        is known to have some nasty bug in it) been copied?"  (So those copies can be
        fixed, too.)"
        ]]]
        
        A more concrete form of this question is also: "To which tags was version X of
        file FOO copied?", i.e. "Which tags are 'attached' to this version of FOO?".
        Though this probably would require svn to know which paths are tags and/or
        branches (or just show all locations-copied-to, and let the user or GUI client
        figure it out?)
        
        Maybe this successor info could be optionally included with "svn log" output
        (allowing similar ways to view this information like CVS did - all tags
        'attached' to the respective revisions)? 
        
        Some recent discussion about this on the users list (referring to the need to
        track successors): http://svn.haxx.se/users/archive-2010-04/0484.shtml
        

        Show
        jcorvel Johan Corveleyn added a comment - Re: [[[ - answering the question, "To how many places has version X of file FOO (which is known to have some nasty bug in it) been copied?" (So those copies can be fixed, too.)" ]]] A more concrete form of this question is also: "To which tags was version X of file FOO copied?", i.e. "Which tags are 'attached' to this version of FOO?". Though this probably would require svn to know which paths are tags and/or branches (or just show all locations-copied-to, and let the user or GUI client figure it out?) Maybe this successor info could be optionally included with "svn log" output (allowing similar ways to view this information like CVS did - all tags 'attached' to the respective revisions)? Some recent discussion about this on the users list (referring to the need to track successors): http://svn.haxx.se/users/archive-2010-04/0484.shtml
        Hide
        cmpilato C. Michael Pilato added a comment -

        I might be able to get this effort going again in 1.9.
        

        Show
        cmpilato C. Michael Pilato added a comment - I might be able to get this effort going again in 1.9.
        Hide
        julianfoad Julian Foad added a comment -

        Bump all open 1.9-consider issues to 1.10-consider, now that they have missed
        the boat for 1.9.
        

        Show
        julianfoad Julian Foad added a comment - Bump all open 1.9-consider issues to 1.10-consider, now that they have missed the boat for 1.9.

          People

          • Assignee:
            Unassigned
            Reporter:
            cmpilato C. Michael Pilato
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development