Change 1405
Phew - this was a big one!
New functionality:
The rare case in which a revision has multiple parents, due to
multiple resolves before submit, is now handled properly. There
is no limit on the number of "parents" a revision may have.
Integration lines are now always "weighted" to indicate whether
they contributed all, some, or none to the target. For example,
a "branch" line will be very solid and wide, whereas an "ignore"
will be thin and faint.
Rearchitecture:
Now using low-cost structs to keep track of integration information.
Also being just a little more efficient with scanning through large
data structures. Quite a bit of general code bloat trimmed off now
that some of the kludges are gone.
Possible problems:
Not sure yet, but it might happen that "duplicate" integration
pointers will be created, now that it's not a single variable which
would get overwritten in the event of a duplicate.
to-do:
Trim off obsolete member variables. Use more enums and fewer #defs.
New functionality:
The rare case in which a revision has multiple parents, due to
multiple resolves before submit, is now handled properly. There
is no limit on the number of "parents" a revision may have.
Integration lines are now always "weighted" to indicate whether
they contributed all, some, or none to the target. For example,
a "branch" line will be very solid and wide, whereas an "ignore"
will be thin and faint.
Rearchitecture:
Now using low-cost structs to keep track of integration information.
Also being just a little more efficient with scanning through large
data structures. Quite a bit of general code bloat trimmed off now
that some of the kludges are gone.
Possible problems:
Not sure yet, but it might happen that "duplicate" integration
pointers will be created, now that it's not a single variable which
would get overwritten in the event of a duplicate.
to-do:
Trim off obsolete member variables. Use more enums and fewer #defs.
Tip: Use n and p to cycle through the changes.