On the subject of "faster, cheaper, better":
Sander:
> For the sake of this discussion I'm ignoring cherry picking
> for now.
> [...]
> The goal of this proposal is to come up with a scheme that will
> make the:
> svn merge URL .
> [...]
> For sake of simplicity I'm leaving the handling of tree
> deltas out of this proposal.
> [...]
> Merging will rely heavily on variance adjusting.
The patch-log merge history mechanism I'm advocating already supports
cherry picking nicely. (In case I haven't been explicit enough: I'm
advocating lifting the design for that mechanism straight out of arch,
treating the current arch version as a strong prototype, and doing the
necessary design-work/reimplementation to both unify it with svn and
implement in a form more portable to windows platforms.)
Rather than a single `merge' command that goes with that patch-log
mechanism, there are several different mechanisms, each useful in
different circumstances. In practice, I've had the experience of
trying a merge two or three different ways and picking the one that
gives the results that need the least editing. (In arch terminology,
`update', `replay', and `star-merge' are the big three -- with others
to follow later.)
Whole-tree merging in arch has nice solutions already worked out for
the handling of tree deltas.
There is no current implementation of variance adjusting built on top
of patch-logs, but all of the necessary history information is there.
It would be easy to add support for diff4-style merging to this
framework given either a suitable implementation of diff4, or an
implementation of some "patchutils" that perform variance adjustment
on patch sets.
I'm not trying to be smarmy or obsequious when I say that I can see
uses both for what Sander is proposing and what I'm proposing. They
are potentially complementary features.
However, my read on it is that what I'm proposing is much less work to
implement, with much less impact on the core of svn, and while it
loses out on "subtree merging" (or "partial merging"), it wins a lot
by giving quick access to a toolbox of merge strategies rather than a
single one, and opens the door quite a bit to distributed branching
and changeset auditting from the project mgt/business rule
perspective.
I realize my suggestion here (a) is problematic given my status (i.e.,
why I can't just go off an implement it at the moment); (b) risks the
_appearence_ of architectural garishness since it is in a rather
different "style" than existing svn functionality. All I wish to say
is that both of those are solvable problems and should not be a reason
to dismiss the proposal out-of-hand.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 10 23:57:08 2003