> As soon as the next merge, i.e 184.108.40.206, it breaks. CVS is going to
> try to fuse the 1.7->1.10 patch with the 1.7->220.127.116.11 patch. But
> 1.7->1.10 = 1.7->1.8+1.8->1.10 and 1.7->18.104.22.168 ~= 1.7->22.214.171.124+1.7->1.8.
> So they have components in common, hance they _will_ conflict.
> If CVS had taken the latest common ancestor by keeping in the
> repository the existence of the 1.8->126.96.36.199 link, it would have taken
> the 1.8 version as the reference. The patches to fuse would have been
> 1.8->1.10 and 1.8->188.8.131.52, which have no reason to conflict.
> Same for the next merge, the optimal merge point is in that case 1.10,
> and it ends up being a null merge, i.e. 1.11 is a copy of 184.108.40.206.
> You can see the final structure is a DAG, with each node having a max
> of 2 ancestors. And that's what PRCS and bk are working with,
Aha, so that's why my `mergetree' script (which basically is some directory
recursion around plain RCS merge, with additional support for hardlinking
identical files) works better than CVS, when I merge e.g. linux-2.5.64 and
linux-m68k-2.5.63 into linux-m68k-2.5.64. It always uses the latest common
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- email@example.com
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/