On Mon, 2003-06-30 at 08:16, Tom Lord wrote:
>
> > From: Robert Collins <rbcollins@xxxxxxxxxx>
>
> > On Sun, 2003-06-29 at 18:19, Tom Lord wrote:
>
> > > I haven't seen, yet, any evidence of a high-level, unifying,
> > > simplifying "smart-merge" command.
>
> > I wasn't going to nag, because I know it's on your list -somewhere-, but
> > this prompted me to: give us whats-missing --skip-present, and it will
> > seriously help in the prototyping of smarter merges.
>
> I disagree with that characterization.
Which characterisation? That whats-missing --skip-present will help
[...]? (Thats more of an assertion than a characterisation... but hey
:})
> > star-merge is, at best, a bandaid: All it does is (by definition) a
> > whole tree delta, which means that the changes in previously skipped
> > patches will get incorporated willy nilly (because currently, one skips
> > patches by sync-treeing past them, which makes it look like the patch is
> > present - yet it's not, so it's changes show up in the delta).=20
>
> And that, as well.
>
> We're talking about two distinct kinds of patch-flow, both useful.
They are distinct only in motivation, not in graph traversal logic. What
works for non-branch promotion -will- work great for branch-promotion.
The converse -may- be true, but so far (star merge) is not.
> Star-merge is useful (perfect even) for what might be called "branch
> promotion". In "branch promotion", you have a stable branch,
> satisfying some set of constraints or invariants, and one or more
> development branches of that.
>
> The role of the development branches, in star-topology or hierarchical
> branching, is to develop (on development branches) _candidates_ which
> may or may not become the "next stable revision". When a candidate
> revision becomes the stable revision, that revision is "promoted".
>
> With just a single development branch and a single stable branch,
> nothing special would be needed. The development branch could be
> promoted simply by committing it directly to the stable branch.
>
> Star-merge helps when there are multiple, asynchronously evolving
> development branches. When one is promoted, it's changes need to be
> merged back into its sibling development branches. This pattern can
> be extended as when, for example, a given branch is the stable branch
> for some subordinate development branches, but also a development
> branch to some superior stable branch.
Agreed.
> A real-life situation where this kind of arrangement could be applied
> is the linux kernel: Linus could be replaced by a team of
> integrators, each focused on a different area, introducing a degree of
> parallelism where currently there is a serial bottleneck. My
> understanding is that such parallelism is currently appoximated by the
> "trusted lieutenants" pattern -- star-merging can help take that
> approximation to the next level (especially if combined with, say,
> better facilities for automated testing. How interesting that Linus
> is now working for OSDL.)
I'm not convinced that star-merge will handle the sort of cherry picking
I understand the linux kernel to go through as parts of a partch are
broken out and pushed up the tree. That remains to be seen.
> By way of contrast, cherry-picking is useful for situations we might
> call "rival branches" and situations we might call "free-flow
> development branches". In "rival branches", there is no expectation
> that the branches among which mutual cherry-picking takes place will
> ever fully converge on a common source base. In "free-flow
> development branches", there are periods in which a set of branches
> behave as "rival branches", but then there are also periods when
> subsets of those branches may either fully converge, or converge with
> the exception of a few excluded patchess. (My general impression is
> that you've been working in a context of "free-flow development
> branches", where, for example, you cherry-pick back and forth between
> your stable release branches and development branches, but then also
> sometimes want to (mostly, not entirely) sync those branches, at least
> in one direction)
I'll describe how I've been working below (1).
> As nearly as I can tell, two special problems arise with
> cherry-picking for the tools to address. One is a problem with
> redundant merges. The other is a problem with unwanted changes.
These problems are not limited to cherry picking.
[...]
> > A really smart-merge (much smarter than simple idempotency) will -have-
> > to work up from the patch-tree-traversal-graph. (pragmatically: thats
> > the only thing that differentiates arch from svn / cvs in this regard:
> > we -know- where patches came from and where they are going).
>
> It's just not that simple. It sounds good. It has some vague
> elements of truth. But there's no such thing as "a _really_
> (hyper-intellegent, magically perfect) smart-merge" based on textual
> patching, and there never will be. If you want perfection, take up
> programming-language research and figure out how to get programmers to
> express their programming efforts in extremely high-level semantics
> that are also machine processable. Something like SunLabs' "JackPot"
> is about as close to the front-line in this area as I think you're
> likely to find, and even that has a long ways to go.
My point was that to have some hope of building up to such high level
semantics, there is a foundation that will be needed - and that the
traversal graph is a core part of that foundation.
[..]
> > whats-missing --skip-present is a key tool for manipulating that
> > traversal graph trivially (such as in sh prototypes of smarter merges).
>
> `--skip-present', where that looks only at the New-patches: field and
> decides what to skip based only on that, is too broad a brush.
>
> I tentatively think you want someting _similar_to_ the --skip-present
> features we've discussed, but not quite the same.
There are a number of ways to implement the core that I need. What I
want is -any- such implementation, in whats-missing, that I can leverage
trivially. If I had just a little more time, I'd be forking tla and
generating a patch for you to consider. I don't at the moment (which is
unfortunate).
I realised while drifting off to sleep that there has been a long
running conflation of ideas in this list regarding the algebra of
patches. The general description has been sort-of algebraic, and we've
nutted out a few things precisely (such as changeset defn's).
There are two (perhaps more) mostly orthogonal issues, one of which is
application and generation of changesets onto the same basis (i.e. you
create it, stuff it in the archive and then use it rebuilding a project
tree). The other issue is the logic surrounding patches traversing
branches, and the application (or not) of a changeset to a different
branch than it came from. Thats where idempotent merges come in. (And
that -has- been solved (it really is trivial). It just doesn't solve
backward compatability related issues such as dealing with 'faked' log
entries from a make-sync-tree.
Now, as to how I have been using arch:
using squid as an example:
Firstly: the branches:
I sync my work with a couple of CVS branches - the HEAD branch, and
the 2.5 release branch (for bugfixes).
They sync into similarly named arch branches - squid--HEAD--2.5 and
squid--HEAD--3.0.
I then have a mostly unordered collection of bugfix and feature
branches. I.e. fix-ranges, output-delay-pools, acl ... where I do
isolated development.
Now, I need to do several cross-branch propogation work here.
I need to propogate a fix, once complete, to all relevant branches.
This will happen automagically if I merge it into HEAD, so my normal
fix merge pattern is -like- the stable + devel branch pair Tom
describes.
If a new feature requires a fix, I'll usually do that in an isolated
changeset, either on the current branch (if appropriate to the
branches name) or on a dedicated branch. Then I'll merge the fix
into the feature, and optionally, into HEAD. (I may just have it
merge in via the feature branch).
Often, new features depend on each other to a certain extent. So
I find my self merging the following paths, regularly:
HEAD->featureA
HEAD->featureB
featureB->featureA
Now, note that HEAD patches will propogate to A via two paths.
(Historically, star merge got this wrong. And I expect it still
will - from first principles).
Another common scenario is that I build a production branch for
specific clients, who need new features that aren't HEAD ready (i.e. not
flexible enough), or who need non-HEAD appropriate tweaks. These
features and tweaks come from various branches, and we get the same
multiple path graph.
Lastly, we have the merge back to HEAD once a feature is complete.
Thats simply merging back in all the patches applied to the branch.
Star merge can get this one right, as long as I haven't cherry
picked any fixes from the feature. If I have, then star merge gets
it wrong again.
Rob
--
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.
signature.asc
Description: This is a digitally signed message part
|
