cvn diff, cvn merge, and vendor branches (long)

I said:
>I was thinking about the primary use case of repeated merging in-repos.
>root->A->B->C->D->E--v
>|->1-----^->2--^->3->4
>
>Consider the lower row to be the 'mainline' and the upper row to be the
>'branch'.
>
>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

brane said:
>This is of course totally wrong. The set of predecessors -- or rather,
Brane is of course totally wrong, and for that matter rather offensive.

I hope that other people on the list will take a closer look at what I
proposed, since it's quite easy to implement before 1.0 and impacts
nothing else.

>contributors -- is:
> B => (A, 1, root)
> D => (C, B, A, 2, 1 root)
> 4 => (3, 2, 1, E, D, C, B, A, root)
Yes, I know perfectly well that that's the set of *all predecessors*;
nothing else I said even makes sense without that assumption.
It's not the set of *immediate predecessors*, which is what I was
talking about. Different animal. Were you being deliberately dense, or
were you just not thinking clearly that day?

>You must never the contributor set to just the set of immediate
               ^limit
>ancestors.
And I never said you should; this is a straw man.

> What if E were created by reverting the B->C change? It's set
                                                       ^^^^its
>of contributors would then be
>
> E => (D, B, A, root)
>
>and that would affect the final merge.
No, it wouldn't, not in the scheme I outlined. *sigh*
Take a look at it again. My scheme *works*, and it doesn't *care* that
E is a reversion of the B->C change. Nearest common ancestor in the
final merge is 2. It does a 3-way merge, from 2, between the changes:
2->D->E
and the changes:
2->3->4

Who cares that E is a reversion of the B->C change? Not the merge
routine!

----
Skip the rest if that's sufficient rebuttal for you.
I said:
>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.
Brane said:
>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.
Nothing wrong with 'changeset support', which can certainly be added.  
But that doesn't make it a 'changeset tool'.  A changeset tool is basically 
designed around changesets (with revisions as derivatives of them), 
while Subversion is basically designed around revisions (with changesets 
as derivatives of them).  True, you can get one from the other, but this 
makes Subversion fundamentally not a changeset tool.  Sorry.
Indeed, you could change Subversion's architecture to make it a 
changeset tool with 'minimal redesign'.  But that minimal redesign 
would turn out to involve huge amounts of recoding, enough that it would 
be about as hard as starting over.
I said (regarding the same patch applied to different branches 
issue):
>So I think this problem should simply be declared "will not solve".
Brane said:
>>Nope. Will not solve in 1.0 for pragmatic reasons. 
Duh.  The 'pragmatic reason' is that Subversion's architecture 
isn't designed to support it.
Personally, I'm not even sure it's good to "solve" this problem.  The 
same 'patch' (in the sense of a collection of diffs) applied to different 
branches may do fundamentally very different things, and I sometimes 
think that people should be forced to look at what they're doing when 
they merge branches in that situation.
>_Will_ solve in the
>future, also for pragmatic reasons 
There may be a way to solve this within the Subversion architecture.
But unless you rewrite the Subversion filesystem to treat patches as
first-class objects and revisions as second-class objects, there is no 
easy or general way to solve this.
>-- these days, a changeset engine is
>the only viable solution to source management on large, complex 
>projects.
That's just a blanket statement with zero evidence to back it up.  I 
believe that the specific use case I mentioned first is by far the most 
common, and that anything which can handle that use case is a perfectly 
viable solution to source management on large, complex projects.  At the 
moment, most programs which handle that use case happen to be changeset 
tools.  That doesn't mean they have to be.
I said:
>* 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.
>
Brane said:
>>_Every_ changeset tool handles this one right. That's the whole point 
Sorry, you're wrong; I have a specific example from the Linux kernel 
of BitKeeper not handling this case correctly.
Suppose there's one diff hunk being 'partial merged'.  But on the branch 
this change was actually the result of several different patches (each a 
single diff hunk, if you like), and the other parts of those patches 
*aren't* being merged.  You get the case I'm talking about?  The change 
which is going to be ported from the branch to the trunk was never 
previously considered as a first-class change; it simply arose out of 
other changes, and is being considered as a first-class change only in 
retrospect.
How is a changeset tool supposed to realize that this piece of change is 
redundant with the composition of a bunch of subpieces of other changes?  
It can't, quite simply.  You can try to do better and better, but you 
can never get all such cases.
--Nathanael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org