On Mon, 2002-10-14 at 22:08, Tom Lord wrote:
> rip-the-VM
> \
> ->
> rip-driver-and-VM <-> fancy-new-driver
rip-driver-and-VM -> fancy-new-driver, I think. But that's not an
important detail.
> ->
> /
> 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.
I think that would be easy to get in Subversion, too, once it gets merge
history.
But you still have to remember to do it. I think a system genuinely
tailored for patchset maintenance would prevent the user from even
having to think about rip-driver-and-VM unless there was a conflict
between them. In complicated cases, you may have dozens of these
intermediate patch combinations, none of which are interesting except as
bases for other patch sets. That's the problem I was trying to
identify, and I don't think arch solves it. (A layer on top of arch, or
on top of Subversion or CVS, might solve the problem, although my
experience with that sort of layer-on-top is that it works fine until
something goes wrong, and then it fails in a confusing or catastrophic
manner).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 05:02:43 2002