[Nut-upsdev] git conversion progress

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> On Jan 21, 2012, at 7:38 PM, Eric S. Raymond wrote:
> 
> > Automatically detecting *all* potential merge points is expensive - worst
> > case is O(n**2) in the number of commits.  The workflow is designed around the
> > assumnption that a human will identify potential merge points, test them
> > with "merge", and if they're clean di a "merge perform".
> 
> I thought I finally understood this, but the merge commands are all
> commented out in nut.lift. What is the less-than-O(n**2) heuristic?

Possibly I have not communicated well.  My assertion is that if I
tried to run an automatic detection *for all possible branches and
targets* it would approach n**2 in the number of commits.  For any
*single* source commit, the cost of checking all possible merge
targets is O(n) in the number of commits.  A simple counting argument
gives both complexity bounds.

The merge commands are commented out because I don't want to forget
how to test them, but they don't *work* yet - that is, they throw
errors due to supposedly stale or missing files.  Thus, they're not
ready to be part of the script yet.

> Thank you for clarifying the selection set syntax - I was working from the HTML documentation online which says "Tag and branch locations are bracketed with < >".

Yes, this is to be interpreted in context of the general discussion of
selection sets - the <> notation is just one way of writing a
singleton selection set.

> Also, thanks for the quick update to fix the apparmor branch parent.

That actually exposed a basic bug in my branch-analysis algorithm which
*no other branch triggered*.  Damn am I glad I set up a test on a big and
complicated repo before I shipped...
 
> However, I started looking through some of my previous emails to see
> if there were other merge points that were not yet mentioned in the
> comments in nut.lift, and I ran across an inconsistency in the
> Augeas branch merge. As of the last commit to reposurgeon.git on Sun
> Jan 22 08:12:09 2012 -0500, reposurgeon gets the topology right.
>
> The odd part is that on the Augeas branch itself (including after a
> trunk-to-Augeas merge), the files seem correct. After the
> Augeas-to-trunk merge, though, files such as
> scripts/augeas/nuthostsconf.aug.in revert back to their earlier
> state on the Augeas branch.

That's interesting.  I think it tells me two different things:

1. The semantics of import-stream merge is that if a file occurs in
both "from" and "merge" branches with different content and is not
modified in the merge commit, the state it has afterwards is from
the "merge" branch.  

I suspected this might be the case, actually.  The other plausible
resolution rules for this case (this case (different ancestral
content, no M in the merge commit) are (1) the importer throws an error, (2)
the "from" version overrides, or (3) the most recent version on either
branch is used.

I had a to-do item to ask the import-stream maintainer about this, because
it's certainly going to matter for the merge commands.  

2. We cannot take it for granted that every merge implied by a directory 
copy corresponds exactly to a branch merge in gitspace.

I will look into this further.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>