On 2005.10.13 20:06, Martin Langhoff wrote:
This was tested extensively with kernel dev trees, which have some
nasty merges with very convoluted ancestries. I guess that one of the
reasons that the monsters in the dark that Tom talks about don't
worry me is... if anyone has a collection of freak corner cases for
merges, and low tolerance for the scm dropping the ball, it's the
linux kernel project.
If they don't get bitten by the dragons, what are the chances that my
puny projects will?
Because there are things that you would do in another language (say
Java) that you wouldn't do in C.
For instance, I just might refactor some public class into two new
classes, splitting the original file into two others. I'll rename the
original public class to something else, which will require the file to
be renamed to match. Most of the work done by the original class is
now performed by the other new class that is package private but is
nonetheless in a new file. Most of the old lines of code would end up
in the package private class. I would consider the public class to be
the true decendant of the original, despite the fact that it would
contain fewer lines of the original code.
I'd be amazed if the guessing algorithm the kernel team uses would get
that correct.
_______________________________________________
Gnu-arch-users mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
