Re: [Gnu-arch-users] Re: Cascading patchlogs with star-merge

[Tom Lord]

    > From: Shawn Samuel <address@hidden>

    > Merging by hand is useful where you're merging between different
    > development streams. In any environment where you have multiple
    > mainline archives that are logically federated, and all commits 
    > are always going to percolate up the tree to the master archive, 
    > automated merging is often going to be a requirement. 

There are at least two situations you might be describing.
Consider a tree node and its immediate children nodes.

Either:

(a) At certain points in time, a child node is designated as having
    a state of the tree that should (modulo log files) be identical
    to the next state of the parent node.

    In other words, no merging, per se, is really needed -- `get'
    from the designated child, `commit' to the parent, inform the
    child's sibling nodes to back-merge before specifying a new parent
    candidate.  

    That's fully automatable, of course.


(b) At certain points in time, a child node is designated as having
    recent changes that should be merged into the parent.   At these
    times, the parent may have changes not yet present in the child
    node.

    That can not, in general, be fully automated.   There is nothing
    there that can prevent conflicts from arising during a merge, 
    and those need to be resolved "by hand".

    I exaggerate slightly.   It _can_ be fully automated if the parent
    node is not required to have monotonically increasing quality.
    In particular, an automated process could rename ".rej" and
    similar files, add them to the tree as source, and commit to the
    parent with conflicts in place.    There may be an advantage to
    this:  conflicts will be merged back into the child's siblings --
    and that means that the work of conflict resolution could be 
    distributed along with ordinary development.

But, that aside, I understand that your issue with "cascading log
messages" is really the question of what is meant in both (a) and (b)
by "a child node is designated" --- i.e., the problem of knowing
_when_ to merge (or back-merge).

It seems to me that that "designation" can be semi-automated, but the
details of _how_ it can be semi-automated are deeply
project-specific.  It's a process design question:  what action does a
child node have to take to trigger a propogation up the tree?   Is a
simple `commit' enough?   Or should it be a `commit' with some
additional indication (such as an extra log-file header)?   Or should
it be a commit with some external indication (such as an accompanying
email)?   Likewise, there are choices about the timing of
back-merging.

Arch already makes it fairly easy (mostly by not getting in the way)
to implement a set of (semi- or fully-) automated patch-flow
policies.   

Would it be a Good Thing to provide off-the-shelf implementations of
some policies?    Yes, I think so.   But it's going to take a fair
amount of work before that is accomplished in a really nice way and,
in the meantime, experimenting and accumulating experience with ad hoc
approaches seems like a good way to make progress.


    > I've just started using Arch for personal projects, but already I 
    > can easily see a number of reasons why Arch would've been great at my
    > last shop, where we used ClearCase, and part of what it did that 
    > most SCM's don't (and we needed) is to enable exactly the situation
    > I described above. In this case, I would have setup an auto-merge
    > between archives, but you wouldn't want commits to result when
    > your merge process ran but there were no actual changes to be committed. 

Without further specification of exactly what you mean by "no actual
changes" and a clearer understanding of how to handle exceptional
cases (such as conflicts) -- it's hard to know what features to
provide here.


    > This functionality would be nice to have 

I agree except that we aren't clear yet what "this functionality" is,
exactly.

    > as part of tla commit as an
    > option, 

Not necessarily the right place for it, but that's a minor detail.

    > but I don't see it as a requirement for the arch core. 

I see it as highly desirable for a layer around that core.

    > It would 
    > be just as well to have as part of tla-tools or somesuch, as a wrapper 
    > to tla commit that would fail whenever there were no actual changes to 
    > be committed. Either way, I think it is functionality that would be a
    > useful addition to arch.

Consider the following case.

In the project, there used to be a variable named "foo".   In one of
the child nodes, that variable is still called "foo" and we want it to
continue to be called "foo" for the indefinate future.   In the parent
node, the variable has been renamed "bar".

Some changes are made in the child.   These need to be merged in the
parent.  During merging, there may be conflicts over the foo/bar issue
or the parent may simply fail a test-compile before the `commit'.   So
before the commit to the parent, the changes from the child are
adjusted.

Now a back-merge to the child does not make "no changes".   It won't
pass any automated test of a "merge with no effects".   You need some
additional information that isn't there in the changeset to decide
whether or not a back-merge is needed.

Compare this to a case which is operationally the same, from the
perspective of core arch, but where the issue isn't "foo/bar" but is
instead that the child node has incorrectly called _native_strmp which
happens to not be available on the parent-nodes system.   The
correction of that to strcmp _should_ be backmerged.   But, just
looking textually at the changesets -- this is indistinguishable from
the foo/bar case.

-t