-
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 1) Is this really necessary? Won't list(self.get_opcodes()) work?
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 1) Private functions should just use single underscores
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 1) I'd rather see a "class NotReachedError(Exception)" somewhere and raise that, instead of a typeless string.
-
/trunk/reviewboard/diffviewer/diffutils.py (Diff revision 1) difflib's a standar library module, and should stay in that group
-
/trunk/reviewboard/diffviewer/diffutils.py (Diff revision 1) raise "string" is deprecated. Use raise Exception("string")
-
-
One question; do we need to do anything for migration to work when updating the database schema or will default=0 handle that for us?
Switch to Eugene Myer's O(ND) diff algorithm
Review Request #79 — Created June 17, 2007 and submitted
Information | |
---|---|
chipx86 | |
Review Board SVN (deprecated) | |
trunk | |
Reviewers | |
reviewboard | |
Python's SequenceMatcher had a lot of flaws we had to work around and produced unoptimal diffs. It also prevented us from doing intelligent whitespace trimming or extending it for function name scanning (which we'd like to do someday). I added an implementation of Eugene Myers's O(ND) diff algorithm, which is used in GNU diff and other diff programs. While the diffs aren't always necessarily better, they're a step in the right direction. The whitespace trimming alone should improve many diffs though, especially when indenting code. We remain compatible with the old SequenceMatcher diff wrapper code. A version compatibility flag is stored in the DiffSet model that indicates whether to use the old SequenceMatcher or the new MyersDiffer. This will keep existing review requests and comments intact.
Unit tests passed. I tested several diffs I have here and they all rendered as correctly as one can expect.
-
Man, now that I look a little closer this really does feel like C code. Oh well. After you do the tests you talked to me about, this looks fine. There are certainly little style cleanups that can be done, and I'm sure some careful examination could yield some more pythonic code, but you're the maintainer of this bit, not me ;-)
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 4) You're inconsistent in your number of lines between methods in this class.
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 4) What does the comment here mean? It's not apparent whether it's explaining anything or just old code.
-
/trunk/reviewboard/diffviewer/myersdiff.py (Diff revision 4) This can be made a little bit sexier using "for i, item in enumerate(data)"
-