(I have never used BK; all statements I make about it are based on
published information.)
On Mon, 2002-10-14 at 17:40, Greg Stein wrote:
> 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.
I think this is more an artifact of how Linux development is structured
than a feature of BK. As I understand it, Linus acts as a single point
of integration; he receives finished patches, records them, and commits
them. You could do this with CVS, though it would be slower and
clunkier. Since Linus isn't typically doing his own work, at least not
in that repository, you don't get multiple commits per patch. The
integration process happens on a fairly fast time scale, and developers
merge their patches to the most recent kernel before submitting them, so
conflicts are kept to a minimum.
I've seen Linus ask for (and not get) a feature where the revision
control system tries to find the largest set of recent revisions the
patch does not depend on (based on change adjacency, not semantic
dependencies). I'm not exactly sure why he wants that, but I guess the
idea is that he wants the revision control system to help him map the
actual patch dependencies, independent of the order he applied them.
(Part of the reason I'm skeptical of BK is that Linux is highly unusual
in having a single integrator for a project of that size, and BK seems
to have been designed with the Linux model in mind. Any normal project
would just give commit access to a bunch of developers in order to
reduce the integration burden.)
> 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.
I first considered a system where you use custom revision properties to
track which commits belong to which patchset. But you may find that you
tend to get a lot of merge failures trying to reproduce the individual
patchsets when the patches are in similar files. I'm not 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.
Task branches seem like they would work as long as you don't work on two
dependent patches at once. If you interleave work on rip-the-VM and
rip-the-VM-even more, you'll have to do a merge each time you commit
changes to rip-the-VM.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 02:13:41 2002