[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 26 Jun 2009 11:24:39 +0100

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
Received on 2009-06-26 12:25:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.