List Info

Thread: New - Add quilt-like capabilities to svn's changelist feature




New - Add quilt-like capabilities to svn's changelist feature
user name
2007-09-28 17:15:02
http://subversion.tigris.org/issues/show_bug.cgi?id=2948

                 Issue #|2948
                 Summary|Add quilt-like capabilities to
svn's changelist featur
                        |e
               Component|subversion
                 Version|trunk
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|ENHANCEMENT
                Priority|P3
            Subcomponent|libsvn_client
             Assigned to|issuessubversion
             Reported by|mhagger






------- Additional comments from mhaggertigris.org Fri Sep 28 15:15:02 -0700 2007 -------
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://sav
annah.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/Rea
dMsg?list=dev&msgNo=130364

and discussed briefly in IRC; dlr asked me to create an
enhancement request for it.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org


[1]

about | contact  Other archives ( Real Estate discussion Medical topics )