> That's a description of arch, not a description of how to apply arch
> to the problem I described. (In
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=23241
Ok, let's look at that in detail:
Oh, and here's the problem: what if you have two independent patches,
and a third patch which depends on them both? [....]
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.
So, what's the problem? If I'm understanding you correctly, you have
identified two problems:
A) "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"
B) "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."
Let's start with your two independent patches and the third that
depends on them.
So, linus (we presume) is publishing some line of development.
Let's call this series `linus-1', `linus-2', etc.
Both rip-the-VM and rip-the-driver-interface will be forks from linus'
line:
------------------------> rip-the-driver-interface-0
/ rip-the-driver-interface-1
linus-N --------> rip-the-VM-0 rip-the-driver-interface-2
linus-N+1 rip-the-VM-1 ...
... rip-the-VM-2
....
Both `rip-*' trees record their heritage. When they're done, that
record is used to decide against what tree you should prepare the
diff to send to linus. In the meantime, you can `update' from
linus' line freely into your `rip-*' branches.
Next, since you want `fancy-new-driver' to depend on both patches,
you can create a third local branch. Call it `rip-driver-and-VM'.
Your four branches will be in a star topology:
rip-the-VM
\
->
rip-driver-and-VM <-> fancy-new-driver
->
/
rip-the-driver-interface
The arch command `star-merge' (or, more abstractly, the patch and
history-sensativity logic it implements) will let you merge
into `rip-driver-and-VM' from the other `rip-*' branches, and back
and forth with `fancy-new-driver', repeatedly in a fully automatable
way.
So that solves problem (A).
When you're all done, you can send the deltas of the two `rip-*'
branches against `linus-N'. Let's assume linus merges those.
Then you can `update' (in the arch sense) your `rip-driver-and-VM'
branch against `linus-N+X'. Finally, you can send the
`fancy-new-driver' patch as a patch against `linus-N+X'.
So that solves problem (B).
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 04:07:09 2002