On Mon, 2002-10-14 at 20:12, Greg Hudson wrote:
> 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.
Oh, and here's the problem: what if you have two independent patches,
and a third patch which depends on them both? Now, not only will I have
extra merging to do, but the diff for the third patch needs to be
against the combination of the first two patches.
I'll make this more concrete. Let's say we have rip-the-VM,
rip-the-driver-interface, and fancy-new-driver, and I have coded my
driver to the new VM and driver interfaces so that fancy-new-driver
depends on both of the other patch sets. I create branches:
svn cp trunk tags/starting-point
svn cp trunk branches/rip-the-vm
svn cp trunk branches/rip-the-driver-interface
svn cp trunk branches/fancy-new-driver
Any time I commit a change to rip-the-vm or rip-the-driver-interface, I
have to merge that change into fancy-new-driver; on top of that, when it
comes time to generate a diff for fancy-new-driver, I have no existing
base to diff it against; I'll have to integrate rip-the-vm and
rip-the-driver-interface and diff against that.
Alternatively, I could maintain a fourth branch:
svn cp trunk branches/rip-both
but now I have to do two merges every time I change rip-the-vm and
rip-the-driver-interface--one merge into rip-both and another merge into
fancy-new-driver. And if I forget, nothing goes wrong except that I
wind up submitting incorrect diffs to Linus. (Well, hopefully I will
carefully review my diffs before submitting them.)
It seems like a good patchset system would take care of this as well as
it can. For Linux development, the problem may not come up much,
because work tends to be short-term and limited to the projects of one
developer. For RPMs or other packaging systems, on the other hand,
there can be substantial, long-lived, and highly interdependent changes;
the Red Hat kernel RPM comes to mind.
---------------------------------------------------------------------
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:31:06 2002