Re: patchsets

On Mon, Oct 14, 2002 at 11:37:44AM -0400, Neal D. Becker wrote:
> I am not all that familiar with bk, but it looks to me that bk support
> patchsets. The format of releases on linux kernel supports this.
> You'll see that each release identifies a bunch of patchsets, and that
> each patchset addresses a specific topic. I like that. Each patchset
> is individually traceable.

At some point, the developer(s) identified a particular change or set of
changes as representing one "patchset". IOW, there is still some manual
process to identify the logical patches within a set of revisions/changes.

In Subversion, there is a (potentially) many-to-many relationship between
revisions and patches. Since a revision is the smallest "unit of work", you
really would not want to conflate two patches into a single revision. I
believe this will be true of any revision control system.

The problem then becomes how to organize a set of revisions into a patchset,
and then organize a set of patchsets. The process of identifying the which
revisions belong to which patchsets is human-driven, so the question comes
down to what tools can the system provide to make this easier?

As Noal stated, you could use a task branch to organize revisions into a
patchsets. The set-of-patchsets is then a set of task branches.

As an example, let's say that you've been working on the trunk for the past
few weeks, making changes here and there, for different purposes. You are
happy with the results, so you decide to package up the work and deliver it
"upstream" (e.g. to Linus). You review the work and fine:

Patchset "rip-the-VM" is revisions 57, 61, 62, 63, and 74
Patchset "eepro work" is revisions 58, 59, 60, 64, and 65.

Since you were silly and didn't do these on task branches to start with, you
need to do a bit of funny business to package this stuff up. Start off with
creating the branch from the base of your work:

[ note: none of these have been tested or the syntax verified; use them as
  informational only :-) ]

$ svn cp -r 56 http://svn.example.com/repos/trunk/ \
    http://svn.example.com/repos/branches/rip-the-VM

You can then check that out, or switch a working copy over to it:

$ cd .../trunk
$ svn switch http://svn.example.com/repos/branches/rip-the-VM

Now you want to merge the five changes in:

$ svn merge -r56:57 http://svn.example.com/repos/trunk
$ svn merge -r60:63 http://svn.example.com/repos/trunk
$ svn merge -r73:74 http://svn.example.com/repos/trunk

Then commit this work back:

$ svn commit -m "integrate the patchset"

The next part is creating the patchset. Note that you could skip the commit,
and just create the patch, but you probably wanted to commit it for
posterity. To create the patchset:

$ svn diff > rip-the-VM.patch

Unlike BK, Subversion does not have a builtin mechanism for shipping patches
around to other developers or to the "upstream" repository. In the future?
Sure.

But the basic point is that you can build and maintain patchsets with
Subversion. I like Noel's idea of doing it on task branches. (and you could
always integrate those branches back into the trunk and delete the branch
once you've generated/upstream'd the resulting patch)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org