Parent discrepancy between knits and revisions

[John Arbash Meinel]

Aaron Bentley wrote:
> Hi all,
> 
> I've discovered a discrepancy between the parents of a file's knit, and
> the revision.
> 
> Take errors.py.  The following file versions have >2 parents according
> to the kint:
> 
> robertc at robertcollins.net-20050914172314-4c220f175bb62fe0
> robertc at robertcollins.net-20050927072440-1bf4d99c3e1db5b3
> robertc at robertcollins.net-20050928052554-beb985505f77ea6a
> 
> But according to cat-revision, the actual revisions have only two parents.
> 
> For revision robertc at robertcollins.net-20050914172314-4c220f175bb62fe0
> 
> The revision parents are:
> robertc at robertcollins.net-20050914151159-2986150cde2d744a
> abentley at panoramicfeedback.com-20050914165444-335a16dc80f7c129
> 
> The errors.py parents are:
> abentley at panoramicfeedback.com-20050914165444-335a16dc80f7c129
> abentley at panoramicfeedback.com-20050914163546-ef044baf4ef9c135
> robertc at robertcollins.net-20050914145408-6532b86aa3e8423a
> robertc at robertcollins.net-20050914151159-2986150cde2d744a
> 
> I would have imagined it could be the other way around, due to ghosts.
> But it's hard for me to see a benign explanation for this.
> 
> Aaron

I'm trying to look into this. I ended up writing:
http://bzr.arbash-meinel.com/plugins/kndx_to_dot

To try and help. It is sort of like 'graph-ancestry' but it focuses on a
specific knit, and lets me supply a --start and --end so that I can
actually view the final image. (my machine seems to want to use 500+MB
for a 600 node graph, much less a 10k graph from all of bzr.dev).

Anyway, the specific knit graphs seem quite a bit different than the
global ones. For example the revision:
robertc at robertcollins.net-20050915174807-7c2e9af156dae948

Is very important in 'errors.py', in that 6 revisions seem to decend
from it. But in the revision message is only:
  lalos branch constructor patch

I'm guessing it was Robert's integration branch. One of the decendents was:
  john at arbash-meinel.com-20050917045153-bfa0bd371b0b877e
with message:
  Most tests pass, some problems with unavailable socket recv
with only 1 parent:
  john at arbash-meinel.com-20050917042039-dc735db4fdb689cb


Now, I understand this, because probably my branch derived from Robert's
integration branch, and I didn't make any changes to errors.py until
john--b877e.

So I'm still trying to understand your octopus merge, but my guess is
that it is something like... both sides have merges and both of the
merges modify the file.

For example (see attached):
digraph G {
  a -> c;
  b -> c;
  d -> f;
  e -> f;
  c -> g;
  f -> g;
}

In this case, 'g' would show changes from a, b, d, e (maybe) without
requiring an octopus merge at g.

Now, I'm not positive, because it seems like c and f would have to
record content changes to resolve the merge, so you would still only end
up with 'c,f'.


The other possibility is that it is just a bogusity with our early merge
detection code, considering all of these nodes are fairly old. (Though
that could also be because we worked in more of a mesh before bzr.dev
had multi-committer support).

Probably my next step would be to overlay 2 knit graphs (so you can see
the overall branch history and an individual file history).

So I don't have any easy answers (yet :).


John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mygraph.png
Type: image/png
Size: 1540 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070410/016957c7/attachment.png