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

Add quilt-like capabilities to svn's changelist feature

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: trunk
    • Fix Version/s: blue-sky
    • Component/s: libsvn_client
    • Labels:
      None

      Description

      Briefly: it would be very useful to be able to unapply and re-apply the changes
      associated with a changelist to the working copy.  This would give SVN
      functionality similar to that of "quilt" and also somewhat ease working with SVN
      while disconnected from the main repository.
      
      Background:
      
      It is currently awkward to work with multiple changelists at once.  Suppose I am
      working on a big change when I notice a small cleanup that I would like to make
      and commit.  I create a new changelist called "cleanup", modify a file or two,
      and add them to the changelist.  But it is impossible to test the "cleanup"
      change because my working copy includes modifications for the big change.  I may
      not even be able to compile and run the code, or it may be that the tests pass
      only because of the unrelated changes.
      
      It would be nice to be able to create a second changelist called "bigchange",
      and then *unapply* "bigchange" from my working copy (storing it to a temporary
      location in some kind of patch format).  Then I could test "cleanup", commit it,
      reapply "bigchange", then continue work on "bigchange".
      
      Quilt is a tool that helps such a workflow by maintaining a "stack" of patches.
       Quilt stores patches as diffs in a special directory, and keeps a list of the
      known patch filenames in a text file.  A patch can be applied to a source tree
      by typing "quilt push" and removed by typing "quilt pop".  It is also possible
      to edit the files in the source tree, then incorporate the edits into the
      topmost applied patch by typing "quilt refresh".  Other quilt commands allow the
      user to create and delete patches, inspect patches, etc.
      
      Quilt keeps track of the order of the patches that it controls, and only allows
      them to be pushed and popped in the correct order.  If a patch that is deeper in
      the stack has been modified, it is possible that there will be a conflict when
      pushing a later patch.  Patches are applied using the "patch" program, so simple
      conflicts are resolved automatically; others have to be resolved by the user.
      
      Quilt allows many patches to be managed at once; I routinely have a dozen
      patches under quilt's control.  Apparently some users manage more than a
      thousand patches at once with quilt.  However, quilt is already very useful when
      working with only two or three patches at once.
      
      For more information about quilt, see:
      
          http://savannah.nongnu.org/projects/quilt/
          http://www.suse.de/~agruen/quilt.pdf
      
      It would be very nice to add some quilt-like functionality to SVN's new
      changelist feature by allowing changelists to be pushed and popped off of the
      working copy.  SVN could improve on quilt because (1) it knows what the files
      looked like in their pristine forms; (2) it knows when a changelist has been
      committed (and can therefore be forgotten).
      
      
      One tricky issue when dealing with patches is that they do not commute; in
      general it might be possible to apply patchA followed by patchB, but not patchB
      followed by patchA.  Equivalently, if patchA then patchB are applied to the
      working copy, then it is not necessarily possible to unapply patchA while patchB
      is still applied.  Quilt avoids this problem by keeping track of the order of
      patches, and only pushing/popping them in the correct order.  But such a
      restriction might not fit in with SVN's implementation of changelists.
      
      Another possibility would be to enforce the following restriction: two
      changelists may not be applied at the same time if they have files in common. 
      This doesn't prevent the possibility of conflicts, but at least when a file is
      modified it is unambiguous to which changelist the modification belongs.
      
      This idea was mentioned on the dev mailing list
      
          http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=130364
      
      and discussed briefly in IRC; dlr asked me to create an enhancement request for it.
      

      Original issue reported by mhagger

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                subversion-importer Subversion Importer
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: