Re: svn diff, svn merge, and vendor branches (long)
From: Nathanael Nerode <neroden_at_twcny.rr.com>
Date: 2002-12-14 00:44:12 CET
Tom Lord wrote:
To be distributed, we'd simply need "revision@repository" to represent
So much for the unique naming problem.
> 2) The repository-of-reference, the authoritative record of
> 4) The framework for changeset manipulation is made as
>How does all this relate to the problem of "repeated merging"?
> ii) The form in which that history is archived should be
> which is essential for tasks (b-d)
Let's review these:
> c) They should be designing systems in which the changeset
> d) They should be designing systems in which changeset
> "How can we tack some kind of repeated merging support onto svn?" is,
---- 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 * When doing a 'merge', search for the nearest common ancestor and do three-way merge just as is done now. The difference being what counts as a common ancestor. -- What this doesn't handle is partial merges, which a true changeset tool could. * For instance, suppose sometime in the middle of things, the same patch is applied, separately, to both branches. When the time comes to merge one into the other, it will show up as two separate and in theory possibly conflicting patches. (In reality, it will cause interference with other patches to the same area.) 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. So I think this problem should simply be declared "will not solve". * 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. Suppose the change from 1 to 2 is the partial merge. What we normally want here is to add 2 as an ancestor of the branch: root->1->2-v->3 |->A->B--->C->D which of course implies a merge of the changes from root to 1 into the branch. However, partial merges without a merge from mainline are generally bad news, IMHO. I think there's a way to handle this... -- I do not consider merge cases involving a working copy, because the nature of CVS-style working copies is that they do not keep history, except for one single piece of information: which revision the working copy is 'based' on. Accordingly they can't do anything clever. I think that it is correct for the working copy to exist without carrying history with it. --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Sat Dec 14 00:45:51 2002
This is an archived mail posted to the Subversion Dev mailing list.