Nathanael Nerode wrote:
>I was thinking about the primary use case of repeated merging in-repos.
>Consider the lower row to be the 'mainline' and the upper row to be the
>To avoid repeated merging, all we need to do in this case is this:
>* mark B as having predecessors 1 and A
>* mark D as having predecessors 2 and C
>* mark 4 as having predecessors 3 and E
This is of course totally wrong. The set of predecessors -- or rather,
contributors -- is:
B => (A, 1, root)
D => (C, B, A, 2, 1 root)
4 => (3, 2, 1, E, D, C, B, A, root)
You must never the contributor set to just the set of immediate
ancestors. What if E were created by reverting the B->C change? It's set
of contributors would then be
E => (D, B, A, root)
and that would affect the final merge.
>This is a point which a changeset tool handles well and CVS/SVN don't.
>But Subversion isn't designed as a changeset tool, and it's never gonna
>be one; it would require a total redesign.
How nice of you to say so. We've been wondering about how to get real
changeset support into Subversion for _years_, then you come along and
declare that we can stop worrying about it because it's not designed as
a changeset tool. We're well aware of that, and I at least can think of
several ways of adding changeset support on top of what we have, with
>So I think this problem should simply be declared "will not solve".
Nope. Will not solve in 1.0 for pragmatic reasons. _Will_ solve in the
future, also for pragmatic reasons -- these days, a changeset engine is
the only viable solution to source management on large, complex projects.
>* Suppose that we make a 'partial merge' from a branch to mainline,
>consisting of some totally random new changeset, not even composed of
>specific patches on the branch. Same problem, only I bet a lot of
>changeset tools don't handle this one right.
_Every_ changeset tool handles this one right. That's the whole point of
changeset tools -- they can track what's happening to independent diff
hunks, if you like.
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Dec 14 04:02:41 2002