[RFC] Extending/replacing changelists with stackable patches

[Blair Zajac <bl...@orcaware.com>]

I've recently been using stacked git (stg) to work in a git svn clone  
of our Subversion repository.  This has enabled me to replace my 10+  
working copies, named foo-1 through foo-10, with a single working  
copy.  One problem with 10 working copies is that I forget which one  
has what work in it and also finding a new clean working copy when I  
need to start new work.  With stg, I get a feature similar to svn  
changeslists, but I get named patches that form a stack of patches,  
that I can push, pop and reorder, before committing.  I also get the  
ability to have a single file be modified in separate patches and

The typical workflow is

stg new my-new-patch-1 # make a new empty patch
vi foobar
fi barfoo
stg refresh            # now my-new-patch-1 contains those changes
vi foobar              # new changes don't exist in a patch yet
stg new my-new-patch-2 # make a new empty patch
stg refresh            # now the second edit of foobar is in the 2nd  
patch
stg pop -a             # pop all patches, wc now contains no changes
vi bazbaz              # boss called, work on something else
stg new fix-bazbaz     # start new patch
stg refresh            # fix-bazbaz now contains fix for bazbaz
stg commit             # commit fix-bazbaz into git
git svn dcommit        # commit fix-bazbaz into svn
stg push -n 2          # push the first two patches onto the stack and  
into wc
vi foobar              # put more changes into foobar
stg refresh            # refresh my-new-patch-2
stg commit             # commit my-new-patch-1 and my-new-patch-2 into  
git
git svn dcommit        # commit my-new-patch-1 and my-new-patch-2 into  
svn

I've found this to be very useful and nice and has made my life much  
easier.

Notable differences between svn changelists:

1) There is no act of having to put each file into a changelist.  The  
refresh command just associated any outstanding diffs with the patch  
on the top of the stack.
2) The same file can be modified in different patches.

I think the second one is the big one.  Changelists do not work around  
the issue of multiple separate logical changes modifying the same  
file, so you still can end up with multiple working copies.

Without getting into the DVCS issue this idea based on, I think this  
feature could be nicely implemented in svn to give a sense of offline- 
commits.

When the user runs an 'svn update' the client could pop all patches,  
do the update, then push the patches onto the stack and into the wc  
one by one, at which point conflicts could be handled.

I understand stg is similar to quilt, which I haven't used.

Blair

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365567

Re: [RFC] Extending/replacing changelists with stackable patches

[Stefan Sperling <st...@elego.de>]

On Sun, Jun 28, 2009 at 05:32:33PM -0500, Augie Fackler wrote:
> On Jun 26, 2009, at 5:24 AM, Stefan Sperling wrote:
> 
> > Combined with advanced svnpatch functionality (serialised svn://
> > protocol commands encoded in the patch file), we could even encode
> > tree changes in a less lossy way than is possible with plain unidiff.
> 
> If you're going to use something beyond pure unidiff, I'd encourage  
> you to look at git-diffs, which are used by at least Mercurial and Git  
> (no idea about Bazaar), and maybe even add some simple extensions to  
> that format for directory entries and properties if needed. It's been  
> very nice to have a format that has the extra metadata, but still  
> works with patch(1) most of the time.

Too late :)

We already have a Subversion-specific patch format with extra metadata
in trunk. See http://svn.collab.net/repos/svn/trunk/notes/svnpatch
Also works with patch(1), which just ignores the extra info as noise,
which I suppose is the case for Git unidiff extensions also.

The implementation is a bit unwieldy (it implements the whole delta
editor API yet again...), but apparently it works.
In my opinion, it's "just" a matter of refactoring the code a bit
for maintainability before we can release it.

But I could imagine adding support for Git's extensions to unidiff, too.

Stefan

Re: [RFC] Extending/replacing changelists with stackable patches

[Augie Fackler <li...@durin42.com>]

On Jun 26, 2009, at 5:24 AM, Stefan Sperling wrote:

> Combined with advanced svnpatch functionality (serialised svn://
> protocol commands encoded in the patch file), we could even encode
> tree changes in a less lossy way than is possible with plain unidiff.

If you're going to use something beyond pure unidiff, I'd encourage  
you to look at git-diffs, which are used by at least Mercurial and Git  
(no idea about Bazaar), and maybe even add some simple extensions to  
that format for directory entries and properties if needed. It's been  
very nice to have a format that has the extra metadata, but still  
works with patch(1) most of the time.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2366173

Re: [RFC] Extending/replacing changelists with stackable patches

[Stefan Sperling <st...@elego.de>]

On Thu, Jun 25, 2009 at 07:46:58PM -0700, Blair Zajac wrote:
> I've recently been using stacked git (stg) to work in a git svn clone  
> of our Subversion repository.  This has enabled me to replace my 10+  
> working copies, named foo-1 through foo-10, with a single working  
> copy.  One problem with 10 working copies is that I forget which one  
> has what work in it and also finding a new clean working copy when I  
> need to start new work.  With stg, I get a feature similar to svn  
> changeslists, but I get named patches that form a stack of patches,  
> that I can push, pop and reorder, before committing.  I also get the  
> ability to have a single file be modified in separate patches and

This sounds much like Mercurial Patch Queues, which I have come
to love while preparing patches for inclusion in other projects:

http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html

> Without getting into the DVCS issue this idea based on,

I don't see how the idea of a patch stack is related to DVCS.

> I think this  
> feature could be nicely implemented in svn to give a sense of offline- 
> commits.

Agreed, I'd very much like to see something like this in svn.

Combined with advanced svnpatch functionality (serialised svn://
protocol commands encoded in the patch file), we could even encode
tree changes in a less lossy way than is possible with plain unidiff.

Stefan