Re: patchsets

>> rip-driver-and-VM <-> fancy-new-driver
> rip-driver-and-VM -> fancy-new-driver, I think.

This is illustratrive.

I was presuming that you'd want to send linus the `fancy-new-driver'
patch after he'd accepted the two `rip-*' patches. So, merging back
from `fancy-new-driver' to the hub branch makes sense in terms of
preparing for that submission.

> I think that would be easy to get in Subversion, too, once
> it gets merge history.

I'm increasingly convinced you don't need it, and don't really want it
(other than as a layer). You're architecturally optimal (pretty much
by definition) for "big bag of programmers" as-is, and a mostly
orthogonal arch layer gives you fancy merging where you need it most.

It's neat if the technology used for each shop's internal revision
control is orthogonal to inter-shop change-set management -- my simple
proposal does that.

> 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.

That get's into workflow-based client UIs. I agree that that's the
future and implies reconceptualizing svn as a storage manger, freezing
and, if anything, simplifying the existing interface, and starting to
think of layers on top of that.

I can't believe you guys (core svn developers) aren't biting at that.
It would let you focus on the things you're already way ahead on, and
not worry too much about the promised things that will never quite
work out.

-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 05:21:56 2002