--- Tom Lord <lord@regexps.com> wrote:
> > 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).
These sound like integration branches. Are they?
Why couldn't the above be done in Subversion?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 14:22:49 2002