[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn diff, svn merge, and vendor branches (long)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-12-14 04:01:57 CET

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

>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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 04:02:41 2002

This is an archived mail posted to the Subversion Dev mailing list.